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Purpose 


Preface 


The Oracle Names Administrator's Guide provides the information you 
need to understand and use the Oracle Names product. Oracle Names 
makes network address and database link information in an 
enterprise-wide distributed database network available to all nodes 
throughout the network. 


Note: This manual contains examples and figures that refer to 
specific machine types, network protocols, and operating 
systems. These references are examples of possible 
configurations and are not representative of all configurations. 
Use this guide in conjunction with an Oracle operating, 
system-specific manual that includes notes on installation and 
O8Dec operating system-specific information such as configuration file 
locations and protocol support on that platform. 
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Audience The information in this manual is intended primarily for network or 
database administrators (DBAs). This guide is also for anyone who 
wants to understand how Oracle Names works. 


Documentation Set Use this guide in conjunction with the other manuals in the Oracle 
network products documentation set. This set consists of manuals that 
help you to set up an integrated, heterogeneous network and to use the 
applications and services provided. The documentation consists of the 
following manuals: 


o Oracle Names Administrator's Guide (this manual) 


Describes the Oracle Names product, including 


Names 


- the purpose and function of Oracle Names 
— types of network naming schemes 


— configuration requirements for Oracle Names 


= 


he Dynamic Discovery Option 


Refer to this manual to learn how Oracle Names works, and how 
to use it after it is installed and configured. 


Oracle operating system-specific manuals include installation 
instructions for the networking products on your platform, and 
describe the Oracle Protocol Adapters, including: 








— protocol terms and concepts 


{ - protocol-specific parameters 





Refer to this book for installation instructions and other 
information that is platform or operating system-specific. 


== . e Oracle Network Manager Administrator's Guide 


“Describes the tool that creates the configuration files for the 
Oracle networking products, including: 


- SQL*Net release 2.3 
~ Oracle MultiProtocol Interchange 


NetMan 


~ Oracle Names 
Use this book when you want to configure the SQL*Net network. 
o Understanding SQL*Net 
Describes SQL*Net release 2.3, including: 
~ SQL*Net functionality 
- architecture of SQL*Net 





SQLNet 
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— planning your SOL*Net V2.3 network 
— using SQL*Net V2.3 


Refer to this book to understand how SQL*Net works, and how to 
use it after it is installed and configured. 


e Oracle MultiProtocol Interchange Administrator’s Guide 





$ Describes the Oracle MultiProtocol Interchange, including: 
ntchg 


the purpose and function of the Interchange 


— using the Interchange to navigate connections over a 
network 


client choices for accessing the Interchange 


using the Interchange in a network 


Refer to this book for information about the functions of the 
Interchange and how to use it after it is installed and configured. 





e Oracle Network Products Troubleshooting Guide 


Contains errors and diagnostic information, including: 


Diagnostics 


How this Manual Is 
Organized 


- information about coping with errors and using diagnostic 
features of Oracle network products, most notably tracing 


~ the error messages and informational messages that may 
occur during network processing 


Use this book for troubleshooting help. 
The Oracle Names Administrator's Guide consists of the following chapters 
and appendices. : 
Chapter 1 ~ Introduction to Oracle Names 


This chapter describes the purpose of the Oracle Names product, 
including the Dynamic Discovery Option, and provides an overview of 
its administration and requirements. It also provides information to help 
you decide whether or not to use the Dynamic Discovery Option. 


Chapter 2 - Introduction to the Dynamic Discovery Option 


This chapter describes the operational architecture of Oracle Names 
using the new Dynamic Discovery Option provided with SQL*Net 2.3. 


Chapter 3 - Oracle Names Architecture 


This chapter describes the operational and functional architecture of 
Oracle Names without the Dynamic Discovery Option. 
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Chapter 4 - Planning for Oracle Names 


This chapter describes the issues to consider before setting up a network 
with Oracle Names. 


Chapter 5 - Setting Up and Running Oracle Names with the Dynamic 
Discovery Option 


This chapter provides scenarios that show how to set up and upgrade 
your network to Oracle Names 2.0 using the new Dynamic Discovery 
functionality, a significant enhancement to Oracle Names 2.0. 


Chapter 6 - Configuring Oracle Names 


This chapter describes how to configure Oracle Names for your system. 
Also included are Names Server parameters. 


Chapter 7 - Running and Managing Oracle Names 


This chapter describes the operations required to maintain the Oracle 
Names system after it has been installed and configured. 


Appendix A - Oracle Names Control Utility Reference 


This appendix describes the commands available in the Oracle Names 
Control Utility NAMESCTL. 


Appendix B - Complex Network Issues and DDO 


This appendix describes complex network issues that arise when 
converting your network, or part of your network, to using the DDO. 
This Appendix is intended to be used only as a reference chapter. 


Appendix C - Advanced Topics 


This appendix discusses advanced topics in setting up Oracle Names. 
Discussed are such topics as defining foreign regions, defining client 
profiles, and resolving names in domains. 


Related Publications In addition to this guide, the other manuals in the SQL*Net 
documentation set, and the Oracle operating system-specific 
documentation for your platform, you may want to refer to the 
following documents published by Oracle Corporation: 


e Oracle7 Server Concepts 

© Oracle7 Server Administrator's Guide 

e Oracle7 Server Application Developer’s Guide 
e SQL*Plus Reference Guide 

© SQL Language Reference Manual 
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Notational 
Conventions 


Your Comments Are 
Welcome 


The following syntax conventions are used in this manual: 


text...italic 


Monospace 
normal 


Monospace 
italics 


[] 


Punctuation 


UPPERCASE 


Italic text is used for emphasis, to call attention to a 
technical. term used for the first time, and to 
differentiate coding terms used like words within 
text. 


Monospace shows computer display or contains 
text you need to enter exactly as shown. 


Monospace in italics represents a variable. 
Substitute an appropriate value. 


Brackets enclose optional items. Do not enter the 
brackets. 


A vertical bar represents a choice of two or more 
options. You must enter one of the options. Do not 
enter the vertical bar. 


Punctuation other than brackets and vertical bars 
must be entered as shown. 


Uppercase characters within the text represent 
command names, filenames, and directory names, 


We value and appreciate your comments as an Oracle products user. As 
we write, revise, and evaluate our work, your opinions are the most 
important input we receive. At the back of this manual is a Reader’s 
Comment Form; we encourage you to use this form to tell us what you 
like and dislike about this (or other) Oracle manuals. If the form is 
missing, or you would like to contact us, please use the following 


address: 


Oracle Network Products Documentation Manager 
Oracle Corporation 
500 Oracle Parkway 


BOX 659410 


Redwood Shores, CA 94065 
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CHAPTER 


Introduction to 
Oracle Names 


T his chapter describes Oracle Names 2.0, including a general 
overview of the product and some of the key components. This chapter 
also discusses the new Dynamic Discovery Option, or DDO, which 
allows an administrator to install and use Oracle Names 2.0 with 
minimal configuration. Oracle Names 2.0 is included with the release of 
SQL*Net 2.3. 


The difference between Oracle Names version 1.0 and version 2.0 is the 
Dynamic Discovery Option. If you choose not to use the Dynamic 
Discovery Option, then both versions are basically the same. Both are 
compatible with SQL*Net version 2.0 and later. 


iS Attention: The Dynamic Discovery Option only works on 
nodes that use SQL*Net release 2.3. Services will not be 
automatically registered if SQL“Net release 2.3 is not used, and 
clients will not be able to find the well-known Names Server. 
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What Is Oracle Names? 


Oracle Names version 2.0 is a supporting product for Oracle7 release 7.3 
and SQL*Net release 2.3. Oracle Names makes network address and 
database link information available to all nodes throughout the network. 
Each database server's network address is stored with a name that is 
used to identify it. Client applications can then request a database 
connection with a simple name rather than a lengthy address. 


Ps ORSINI S 
What Is the Dynamic Discovery Option (DDO)? 


Oracle Names 2.0 with the Dynamic Discovery Option enables 
configuration free networking while providing all the functionality of 
Oracle Names 1.0. 


Note: The Dynamic Discovery Option is most appropriately 
used in a single community network. Oracle Corporation does 
not recommend using this option in complicated networks. For 
recommendations on when to use the Dynamic Discovery 
Option, see the section, “Choose Whether to Use the Dynamic 
Discovery Option” later in this chapter. 


The new features of the Dynamic Discovery Option include: 
e Well-known Names Servers 


A well-known Names Server is a server with an address that is 
hardcoded into the Oracle Names Server and its clients. The 
well-known Names Server is known, or available, at this address, 
so that clients do not need to be told, by way of configuration 

: files, where to find the Names Server. 


e Dynamic service registration 


When a service starts up, it registers itself with the first 
well-known Names Server it locates. All listeners and databases 
are registered automatically with an Oracle Names Server at 
specific well-known name and address. 


e Replication of service definitions 


Well-known Names Servers continually reconcile the contents of 
their cache with those of other active well-known Names Servers 
on the network. Therefore, an object only has to register itself 
once with any Names Server for it to be registered across the 
network. 
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Choose Whether to Use the Dynamic Discovery Option | 


The new Dynamic Discovery Option in Oracle Names 2.0 is not for 
every network. There are several factors that you need to consider 
before using DDO on your network. 


e If you are setting up a new network, using the Dynamic 
Discovery Option is a good choice. DDO enables all SQL*Net 2.3 
services on the network to self-register with a well-known 
Names Server. This eliminates the need for any preconfiguration 
or maintenance on the part of the network administrator. 





e Ifyou have a simple existing network that is growing, the 
Dynamic Discovery Option is a good choice. Administrative | 
changes can be made in a central location, and distributed to all 
the clients on the network. 


e Ifyou have multiple naming domains in your network, or expect 
to grow to the point of needing multiple naming domains, using 
the DDO is not a good choice. The DDO relies on the existence of 
a flat naming space. While a flat name space is convenient for 
small, local installations, it is not suitable for large, 
enterprise-scale networks. 


+ Ifyou have a network that stays the same for long periods of 
time, whether large or small, converting the network to use the 
Dynamic Discovery Option may not be worth the effort. Static 
networks, especially small ones, are easy for an administrator to 
update or maintain manually. 


e Ifyou have networks which include gateways or MultiProtocol 
Interchanges, Oracle does not recommend the DDO for this type 
of network. - 


e Administrators of networks currently using Native N aming 
Adapters might find upgrading to DDO more troublesome than 
its benefits warrant. ' 


See Chapter 2, “Introduction to the Dynamic Discovery Option” and 
Chapter 5, “Setting Up and Running Oracle Names with the Dynamic 
Discovery Option”, for more information. 


Note: Remember to plan for the migration before you begin. If 
you have a large or complex environment, you need to make 

sure that your migration plan will not isolate any existing users | 
from accessing any data. 
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Compatibility Between Oracle Names versions 1.0 and 2.0 


The Dynamic Discovery Option in Oracle Names version 2.0 is the only 
difference from Oracle Names version 1.0. If you choose not to use 
DDO, then Names Servers for Oracle Names version 1.0 and Oracle 
Names version 2.0 are basically the same. 


iS Attention: DDO only works with nodes using SQL*Net 2.3. On 


Das A aT S 


Why Use Oracle Names? | 


all other versions of SQL*Net, service information must be 
entered into the network using Oracle Network Manager, and 
the clients need the appropriate configuration files. For more 
information on network configuration, see Chapter 5, Setting 
Up and Running Oracle Names with the Dynamic Discovery 
Option”, and Chapter 6, “Configuring Oracle Names”. 


There are many benefits to using Oracle Names including: 


© Oracle Names eases the burden of administering the details of the 
network. If the address of a network object changes, the change is 
made in one place, and all clients get the benefit of the change 
immediately. Any number of clients have access to a network 
object’s address from a single source. 


e The user and application developer are exposed only to the name 
of a network object. No knowledge of the connection path is 
required. This is a much more user-friendly way to use networks 
and network services. As with other user-oriented network 
software such as electronic mail, people only need to think in 
terms of names to get their work done. When making a 
connection, the client specifies the name of a destination and 
Oracle Names provides the address. 


Such administrative advantages are critical to managing large 
distributed systems. In a production environment, it’s important that 
users and applications be shielded from changes made to the network 
infrastructure. In the long run, this results in less work for the 
administrator and more reliability for the network. 


Why Use Oracle Names with the Dynamic Discovery Option 


The Dynamic Discovery Option enables network listeners and Oracle7 
Servers to automatically register themselves with a well-known Names 
Server at a specific well-known address. Therefore the need for 
configuration files is significantly reduced. The only required 


1-4 Oracle Names Administrator’s Guide 


configuration file is a LISTENER.ORA for each listener, which is created 


automatically during database installation. 


Note: Other configuration files are required only if you want to 


have non-default values for some of your configuration 
parameters. See the section “Non-default Parameters” in 
Chapter 5 of this manual. 


The DDO enables clients and services to find the well-known Names 
Server, automatically update Names Server addresses and database 


links as changes occur, and propagates these changes to other 
well-known Names Servers. This eliminates the need for extensive 
configuration files, and maintenance of those files. 


Bsa RNA Su A SUDAN HO RMR] 
What Is Stored in Oracle Names? 


An Oracle Names Server stores names and addresses for network 
services such as databases or MultiProtocol Interchanges, database 
definitions, and object aliases. 


The Names Server stores the following types of objects, which are 
described below: 


link 


e database service names—The service name is the global database 
name that is mapped to the SQL*Net connect descriptor. The 
combination of a listener address and connect data make up a 
connect descriptor that locates a database service. Gateways to 
non-Oracle databases and Oracle RDB databases are also stored. 


+ database links—Global database links are automatically created 





to each defined database from all database servers in the network. 


These links are made available to all users. 


e aliases—You can assign service name aliases as alternate names 
for any defined database service or database link. Service name 


aliases are resolved as if they were the original object. 


e Vi connect strings—A V1 connect string can be mapped to a 


service name in the Oracle Names database. The service name 


you enter acts as an alias for the SQL*Net V1 connect string, 
making it easy to access a server in a network that still uses 
SQL*Net V1. 


e MultiProtocol Interchange names and addresses 
e Names Server names and addresses 


After services have been defined in Oracle N: ames, users only need 


to 


refer to them by name to connect to a database or network service. The 
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necessary exchange of details occurs between the requester and the 
Oracle Names Server. 


With the Dynamic Discovery Option 


There is no difference in what can be stored in Oracle Names version 1.0 
and version 2.0 with the Dynamic Discovery Option. The only difference 
is that with the Dynamic Discovery Option, SQL*Net release 2.3 
listeners register themselves and their databases automatically with an 
Oracle Names Server at a specific well-known address. 


If you need to add services that are not automatically registered, such as 
Interchanges, aliases, and gateways, you will need to use Oracle i 
Network Manager to configure what is stored in Oracle Names. See 
Oracle Network Manager Administrator's Guide for information on how to 
configure Oracle Names with Network Manager. 


Who Uses Oracle Names? 


Oracle Names has many users and one or more administrators. 


The true user of Oracle Names is always either a client application in a 
client-server connection, or an Oracle server in a distributed database. 
Oracle Names is not visible to the user or the application programmer. 


Oracle Names is administered by one or more people using the Oracle 
Network Manager and the Oracle Names Control Utility, or 
NAMESCTL. Oracle Names usually has at least one assigned 
administrator, although the data it stores may come from many sources. 


LAS AE SEI 


System Requirements for Oracle Names 


There are a small number of requirements for an Oracle Names Server. 
It must run on: 


e A multi-tasking computer 


e A computer that can participate in a TCP/IP network. The 
protocol the computer uses must be common to at least one of the 
protocols in the network. 


i= For specific information on memory and CPU requirements, refer 
B to your Oracle operating system-specific manuals. They include 
OSDoc installation instructions and other platform and operating 
system-specific information. 
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The memory required depends on the specific platform and the amount 
of data to be stored. In general, Oracle Names does not require a lot of 
memory, but if there is a large volume of data, more memory may be 
required. 


Dannan Se son enna an Nia ar 
Where to Go From Here 


Deciding which migration strategy to use can be problematic. At the 
very least you should read the section “Choose Whether to Use the 
Dynamic Discovery Option” in this chapter. This section provides you 
with basic guidelines to help you decide whether using Oracle Names 
2.0 with DDO is worthwhile for your network. 


Once you have decided on a strategy, the following guidelines will help 
you determine which sections of this manual you need to read. 


If you are setting up a new network and plan to use the DDO, read: 
e Chapter 2 “Introduction to the Dynamic Discovery Option”. 


After reading the chapter, go to the procedure outlined in 
Scenario 1 in Chapter 5 “Setting Up and Running Oracle Names 
with the Dynamic Discovery Option”. 


If you want to learn more details about the Oracle Names 
product, you may also be interested in reading Chapters 3 and 4. 


If you have an existing network and plan to use the DDO, read: 
+ Chapter 2 “Introduction to the Dynamic Discovery Option”. 


After reading the chapter, go to the procedure outlined in 
Scenario 2 or 3 in Chapter 5, “Setting Up and Running Oracle 
Names with the Dynamic Discovery Option”. 


e Chapter 3 “Oracle Names Architecture”. 
e Chapter 4 “Planning for Oracle Names”. 


+ Chapter 5 “Setting Up and Running Oracle Names with the 
Dynamic Discovery Option”, 


If your network is more complicated than the scenarios presented in 
Chapter 5, “Setting Up and Running Oracle Names with the Dynamic 
Discovery Option”, see Appendix B, “Complex Network Issues and 
DDO” which provides guidelines for more complicated networks. 
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If you choose to run your network without using DDO, read: 
+ Chapter 3 “Oracle Names Architecture”. 
e Chapter 4 Planning for Oracle Names”. 


Follow the procedures in Chapter 6 “Configuring Oracle Names”, and 
Chapter 7 “Running and Managing Oracle Names” to configure Oracle 
Names 2.0 without DDO on your network. 
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Introduction to the 
Dynamic Discovery 
Option 


CHAPTER 


T his chapter describes the Dynamic Discovery Option, or DDO, in 
detail. It covers the following topics: 


e What is Oracle Names with the Dynamic Discovery Option? 
e How a network works with the Dynamic Discovery Option 
+ Oracle Names architecture with the Dynamic Discovery Option 


° Key components in Oracle Names with the Dynamic Discovery 
Option 
IF Attention: The Dynamic Discovery Option only works on 
nodes that use SQL*Net release 2.3. Services will not be 
automatically registered if SQL*Net release 2.3 is not used, and 
clients will not be able to find the well-known Names Server. 
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What is Oracle Names with the Dynamic Discovery Option? 


Oracle Names 2.0 with the Dynamic Discovery Option enables you to 
have configuration free networking while providing all the functionality 
of Oracle Names. The new features include the following: 


e well-known Names Server addresses 
e dynamic service registration: 
e replication of service definitions 


The following sections describe in detail each of the new Dynamic 
Discovery features. 


Well-Known Name Server Addresses 


Oracle Names 2.0 with the Dynamic Discovery Option allows you to 
define a well-known service address for up to five Oracle Names Servers. 


In Dynamic Discovery networks, well-known Names Server addresses 
are hardcoded into both the Oracle Names Servers and their clients. 
Oracle Names Servers are available at these well-known addresses, so 
that clients do not need to be told, by way of configuration files, where 
to find the Names Server. This effectively eliminates the need for the 
administrator to distribute the SQLNET.ORA configuration file so that 
clients can find the appropriate Names Server. 


Note: Your network can have no more than five well-known 
Names Servers, that is, Names Servers that use the Dynamic 
Discovery Option. 


Dynamic Service Registration 


2-2 


Oracle Names 1.0 required administrators to enter the names and 
addresses of all databases in the network into Oracle Network Manager. 
Network Manager then created a network definition which it stored in a 
database. Each Names Server loaded the network definition when it is 
started. 


Oracle Names 2.0 architecture using the Dynamic Discovery Option 
now supports dynamic service registration of Names Servers, network 
listeners, and database servers. 


When a network listener using SQL*Net 2.3 is started, it automatically 
registers itself and the database(s) it listens for with a well-known 
Names Server. 
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Replication of Service Definitions 


Since well-known Names Servers continually reconcile the contents of 
their cache with those of other active well-known Names Servers, 
registration with a single well-known Names Server is sufficient for an | 
object to be known by all the well-known Names Servers on the 
network. This concept is known as service replication. 


How a Network Works Using the Dynamic Discovery Option 


When you create a new, network that includes SQL*Net 2.3 and Oracle | 
Names 2.0 with the Dynamic Discovery Option, you do not need to 
create any configuration files, and therefore you do not need to use 
Network Manager. The only configuration file you need is a 
LISTENER.ORA for every node with a database listener. This file is 
created automatically during installation. 


Note: Other configuration files are required only if you want to | 
have non-default values for some of your configuration 
parameters. For more information see ”Non-default 
Parameters” in Chapter 5. 


The administrator needs to provide YP or NIS aliases for each of the 
machines that will become well-known Names Servers. The required YP 
or NIS aliases are oranamesrvr0, oranamsrvr1, oranamesrvr2, 
oranamesrvr3, oranamesrvr4. The TCP/IP port used by the well-known | 
Names Server is 1575, This information is hard-coded into clients and 

i '” services in the SQL*Net 2.3 network. 





| 
< | 
Once the Names Server comes up, it listens at a well-known address. | 
Then listener is started and registers itself and the services for which it 

listens, with a Names Server. The client, listener or service then attempts | 
to register with the Names Server on a node given one of the following 

aliases oranamesrvr0—4. By default it will try to register first with | 
oranamesrvr0. If that Names Server is not available, it tries to register 

with oranamesrvr1, and so on. When a Names Server receives a 
registration from a service, it immediately replicates that registration to 

all other well-known (and registered non well-known) Names Servers | 
on the network. See your platform-specific documentation for details on | 
how to perform aliasing for your network. l 


Once you have started DDO, the Names Server remembers the | 
addresses of all databases. If a Names Server stops and starts, critical 
network definitions can either be downloaded from another | 
well-known Names Server that is running, or checkpoint files can be 
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retrieved and the integrity of the definition information saved. See the 
section “Checkpoint Files” later in this chapter for more information on 
checkpoint files. 


DN er 


Oracle Names Architecture With the Dynamic Discovery Option 


Oracle Names with the Dynamic Discovery Option eliminates the need 
for preconfigured database addresses. By doing away with 
administration procedures such as manually configuring domains and 
regions, Oracle Names with the DDO significantly reduces the network 
maintenance responsibility of the administrator. 


If your network is currently using a domain based naming model, or 
large enterprise-scale networks which requires the use of domains in the 
future, your network is not suitable for using the DDO. See “Choose 
Whether to Use the Dynamic Discovery Option” in Chapter 1. 


Note: There are certain circumstances in which you may want 
to manually configure a Names Server. Please see “Non-default 
Parameters” in Chapter 5 for more information on how to 
manually configure your Names Server while using the 
Dynamic Discovery Option. 


Change in the Treatment of Domains 


2-4 


Dynamic Discovery networks are not subdivided into regions and 
domains. All services that register are replicated to all well-known 
Names Servers in the network. Therefore, there is no need for Names 
Servers to forward a client’s query to another Names Server in another 
region or domain. If there are Names Servers from previous releases of 
SQL*Net on the network, the well-known Names Servers act as one 
region, and the rest of the Names Servers work as they did in previous 
SQL*Net releases. 


A single region within a multiple region network can use the Dynamic 
Discovery Option. For more information on the procedures for this 
particular network setup, see Appendix C, ” Advanced Topics”. 


Since the names and their definitions are replicated to all Names Servers 
on the network, and are not subdivided between domains, there is no 
longer any real meaning to the domain portion of a name. Names may 
include periods within them, but the domain portion will not get 
interpreted. 
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Default Domains 


For example, when a name is registered with a well-known Names 
Server there is no restriction on the domain portion of the name. Since 
the Names Server is not managing any particular domain, it is not 
required that all names it stores have the same domain(s) in their name. 


Note: If, for any reason you decide to divide the network into 
domains Oracle strongly recommends that you continue to use a 
consistent naming convention in your network. That is, if you 
are using .WORLD, continue to use the naming convention 
WORLD. 


Since DDO is designed to eliminate the need for configuration and 
configuration files, there is no need for a default_domain to be set in 
your network. If you are upgrading a network that has existing database 
domains, Oracle recommends that you continue to maintain the default_ 
domain parameter from existing SOLNET.ORA file. 


If there is no default_domain parameter set, then the service names are 
stored by the Names Server exactly as they are registered. (The name 
which is registered originates from the database name provided in the 
LISTENER.ORA file generated at the time of installation. If the database 
name is EMP, clients use EMP to successfully connect to the database. If 
this name is EMP.ACME.COM the clients will use EMP.ACME.COM. 


If there is a default_domain set using SQLNET.ORA, the 
default_domain will be appended to both unqualified names names 
being registered, and unqualified names being queried. If the default 
domain is WORLD, a database registered as EMP will be EMP.WORLD. 
A database registered as SALES.ACME.COM will not have the 
default_domain file appended because that name is fully qualified. 


Clients using EMP as a connect string get the default_domain appended 
during the name lookup (EMP.WORLD) and this will allow the 
connection to succeed. A query for SALES will also be appended with 
the .WORLD, but this will not match the name registered for the SALES 
database. Clients must use the full name, SALES.ACME.COM to retrieve 
the address of the SALES database. 


Simple names can be made fully qualified by appending a period ”.”. 
For example, the name ” ACME.” will not have the default domain 
appended to it during registration or queries. 
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SESSA 
Key Components of Oracle Names with the Dynamic Discovery Option 


The following section describes the key components of Oracle Names, 
when the Dynamic Discovery Option is enabled. 


With the Dynamic Discovery Option, a network using the Oracle Names 
Service consists of: 


e one or more Oracle Names Servers 


We recommend that you set up at least two Names Servers for 
fault tolerance. 


Note: There must be at least one, but no more than five 
well-known Names Servers when you use the Dynamic 
Discovery Option 


e one or more databases 
e one or more listeners 


e one or more clients 


Figure 2-1 shows the components described above with the Dynamic 
Discovery Option enabled. 
















Database Names Server 





Database 


Names Server 


Client 
Figure 2-1 Components of a Network Using Oracle Names 
with the Dynamic Discovery Option 


Components of a Names Server 


The Oracle Names Server is a network service comprised of multiple 
components. Each Oracle Names Server contains: 
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© the cache—the Names cache is an in-memory database of all data 
required to resolve names. The cache contains the following types 
of data: 


~ system information—includes the service addresses of all of 
the Names Servers. 


— registration information—includes all registered TNS 
services which includes other Names Servers and 
information automatically generated by the Names Server 
when it was installed. 


All cache data is always in memory to guarantee high 
performance. 


e request processor—receives incoming address requests and looks 
through the cache for the answer. 


e forwarder —takes queries for names and forwards the query on 
to the appropriate Names Server. 


Figure 2-2 shows the components of the Names Server using the 
Dynamic Discovery Option and their relationships. 
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Figure 2—2 Oracle Names Server Components 
Using the Dynamic Discovery Option 


Checkpoint Files 


The checkpoint files are internal configuration files. They are described 
here for your information only. If at any time during operation, the 
Names Server cannot get the information it needs to function, it uses the 
checkpoint files. When first started, at regular intervals, and when 
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stopped, each Names Server writes to operating system files known as 
checkpoint files. 
Note: These text files are internal to Oracle Names and should 
not be altered. All changes to this file will be overwritten at the 
next update interval. 


The following is a description of checkpoint files and their function: 


e ckpcch.ora - dynamic registration data cache checkpoint, 
which contains all of the dynamic information before the Names 
Server was stopped. After a crash or restart of the Names Server, 
the previously cached data is loaded from the checkpoint. 

e ckpcfg.ora - Checkpoint configuration, which includes the 
current settings of all configuration parameters. This is used to 
start the Names Server when normal startup information is not 


available. 





Checkpoint files are read only when the Names Server is started, or 
restarted. If a Names Server is started and another Names Server cannot 
be reached, the latest cache checkpoint file is used. This provides the 
Names Server with the latest available data. The cache checkpoint is 
written at every update to capture the latest changes to dynamic 


information. 
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CHAPTER 
Oracle Names 
Ld 

Architecture 

T his chapter describes the architecture of Oracle Names. Included in 
this chapter are discussions on policies and working rules within which 
the product is designed to operate. 

ASAE ENN 


Overview of Oracle Names 


Using Oracle Names requires that you adhere to a set of organizational 
rules. The two most significant organizational entities when you are 
using Oracle Names without the Dynamic Discovery Option are domains 
and administrative regions. 


The following section discusses how Oracle Names 2.0 architecture is 
designed to function on most SQL*Net networks composed of clients 
and databases. 


Note: The difference between Oracle Names version 1.0 and 
version 2.0 is the Dynamic Discovery Option. If you choose not 
to use the Dynamic Discovery Option, then the Names Servers 
are basically the same. Both versions are compatible with 
services on SQL*Net version 2.0 and above. 


Oracle Names Architecture 3-1 


i 
i 
i 





Basic Oracle Names Architecture 


Architecturally, Oracle Names is a network service that provides name 
resolution to Oracle clients and servers. The Oracle Names service 
consists of one or more administrative regions. An administrative region is 
a set of global object names and Oracle Names Servers that are 
administered together through a’single installation of Oracle Network 
Manager. 


Each administrative region has a single installation of the Oracle 
Network Manager through which Oracle Names and other Oracle 
network products can be configured. The tool enables the administrator 
to configure and administer all database listeners, global database links, 
clients, Interchanges, and Names Servers in that administrative region. 


Each administrative region has: 


+ Oracle Network Manager—This tool writes all definitions for all of 
Oracle’s network software, including SQL*Net, the MultiProtocol 
Interchange, and Oracle Names to the network definition ona 
database. It provides a structured way to configure the product 
initially, and to periodically update the network configuration. 


o one or more Oracle Names Servers 
© one or more databases, listeners and clients 


Figure 3 - 1 shows the relationship of the components described above 
with a single administrative region. 


Oracle Names 
Oracle Network Manager servers 





Network definition 
. database 


Figure 3-1 Components ofa Network Using Oracle Names 
Without the Dynamic Discovery Option 
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Oracle Network Manager creates a network definition based on input 
from the administrator, then generates configuration files that can be 
fine tuned for each client. 


Components of a Name Server 


The Oracle Names Server is a network service comprised of multiple 
components. Each Oracle Names Server without using DDO contains: 


e. the cache—the Names cache is an in-memory database of all data 
required to resolve names. The cache contains the following types 
of data which is refreshed at different intervals: 


- systenvand topology data—includes the network data and 
addresses of Names Servers in other administrative regions. 
(Network data includes all communities and MultiProtocol 
Interchanges in the entire network, and Names Server 
addresses in the root administrative region.) 


~ authoritative data ~ data defined within any domain in the 
local administrative region. 


— non-authoritative data — data defined outside the local 
administrative region, for example, foreign database and 
\ Names Server addresses. Non-authoritative data only exists 
in multi-region configurations. 


All cache data is always in memory to guarantee high 
performance. 


e request processor — The request processor receives incoming 
connections and looks through the cache for the answer. 


© forwarder —takes queries for names in foreign regions and 
forwards the query on to the appropriate Names Server. 
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Figure 3-2 shows the components of the Names Server without using 
the DDO and their relationships. 
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Figure 3-2 Oracle Names Server Components 


The sequence of steps involved in the process of resolving a global name 
is outlined in the sections on resolving global names later in this chapter. 


A LT 
Network Models 


There are two simultaneous views of the layout of the network that 
should not be confused: 


+ The community-based model - The layout of the communities 
and the Interchanges that connect them. This is primarily a 
physical relationship among the nodes that applications run on, 
and the network protocols that those nodes use. This is only 
relevant to networks running one or more instances of the 
Multiple Protocol Interchange 


Within the network, each application belongs to one or more 
communities based on the protocols supported by its node. 


+ The domain-based model - Applications are named within the 
structure of the naming model without regard to their place in the 
network. 
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EANIE. WEST.ACME 


Figure 3 ~ 3 shows the community-based network model with 
four database servers, each of which has a database service name 
as shown. This is the typical form of diagram in Understanding 
SQL*Net. 
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MOE.EAST.ACME 
Figure 3~3 Community-Based Network Model 


Note that EANIE and MOE are in the same community but 
different domains. EANIE MEANIE, and MINIE are all in the 
same naming domain, but are in different MultiProtocol 
Interchange community combinations (TCP/IP and DECnet, 
respectively). 


In this example, the two communities, MultiProtocol Interchange, 
and the four database services comprise the network data entered 
into the Network Manager. 


Figure 3 ~ 4 shows a domain-based model with four domains 
(including the root domain). Note that the database service names 
can be divided into either the EAST or WEST domains without 
regard to the communities they are in. 
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Administrative Region 





Root Domain 


Figure 3-4 Domain-Based Network Model 


Be sure you understand the difference between the community-based 
network and the domain-based naming model before configuring the 
network. : 


Naming Models 
There are two basic models for naming objects in the network: 
« Flat naming model 
e Hierarchical naming model 
Flat Naming Model 


All names are unique within a single domain—the WORLD domain. 
The WORLD domain is predefined in the Oracle Network Manager for 
customers choosing a flat naming model. 


Note: A flat naming model should be used when the actual 
number of services is small (under 100), when the likelihood of 
future growth of network services is minimal, and the entire 
SOL*Net network is centrally administered. 
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Figure 3 - 5 shows a flat naming model. The actual database service 
names are appended with ”. WORLD” as in CONFIG.WORLD, 
FLIGHTS.WORLD, ete. 
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Figure 3-5 Flat Naming Model 


‘All names in the WORLD domain must be unique. The Network 


Manager has a validation feature that ensures that all names you enter 
are unique. 


Hierarchical Naming Model 


You can divide names into a hierarchical structure to allow for future 
growth or greater naming autonomy. For example, if a requirement is 
that administrators in Europe must be able to assign names without 
consulting US administrators, they can do so from within different 
domains. This does not mean they must maintain different 
administrative regions, just different domains. A single administrative 
region can contain and thus control many domains. 


Domains 


` All network names include one or more domains. A domain is a group of 


machines and network services. Domains are usually hierarchically 
related for organizational and administrative purposes. However, all 
network names could instead reside in a single domain—the WORLD 
domain. ' 


The top level domain is the predefined root domain. All other domains 
are hierarchically below the root. 


Note: The WORLD domain always appears in Network 
Manager. Because it is not used in hierarchical configurations, 
however, it is not shown in the following figures. 


Figure 3 ~ 6 shows a hierarchical naming model with five domains: the 
(ROOT) domain, ACME domain, US.ACME, EUROPE.ACME, and 
ROW.ACME (Rest of World) domains, 
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(ROOT) ———— Root Domain 
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Figure 3-6 Hierarchical Naming Model 


Within each domain all names must be unique, but across domains they 
can be repeated. Notice that both WEATHER and HISTORY are 
repeated, but the full global names are unique (that is, 
HISTORY.ROW.ACME vs. HISTORY.EUROPE.ACME). 


Network domains are similar to file directories used by many operating 
systems (such as UNIX) in that they are hierarchical; however, unlike file 
systems, network domains may or may not correspond to any physical 
arrangement of databases and other objects ina network; they are name 
spaces. 


You can extend this hierarchy to any number of levels (for example, you 
could divide EUROPE further into UK, GREECE, and so forth.) but each 
additional level increases the knowledge users must retain to request 
names. 


Dividing the set of names into three domains does not necessarily 
require three administrative regions. Administrative regions simply 
represent individual Network Manager installations. ACME may well 
determine that names can be assigned (or decided upon) by the 
administrator in EUROPE or ROW, but forwarded to the administrator 
at the ACME world headquarters in Boise, Idaho to be entered into the 
Network Manager. 


Default Domains 


Each client has a default domain in the naming model. The default 
domain is the domain within which most of the client’s name requests 
are conducted. This is usually the domain the client resides in, but it 
could be another domain from which the client often requests services. 
A client can request a network service within its default domain using 
the service's simple, unqualified name, that is, without specifying a 
domain name. If a user requests a name without a ”.” character in it, the 
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default domain name will be automatically appended to the database 
service or database link name requested. 


Figure 3 -7 shows a client with a default domain of EUROPE.ACME. 
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Figure 3-7 Default Domains 


For more information on domains, refer to Understanding SQL*Net and 
Oracle7 Server Concepts. 


Multiple Domains 


Multiple domains are related hierarchically from the root domain—the 
highest-level domain in the hierarchy—in a series of parent-child 
relationships. For example, under the root might be several domains, 
one of which is called COM. Under the COM domain might be several 
more domains, one of which is ACME. Under the ACME domain might 
be several domains, such as US, UK, and so forth. Each Oracle Names 
system is responsible for at least one domain, but will commonly have 
more. 


Note: Do not confuse domains with SQL*Net communities. A 
SQL*Net community is a group of machines that can 
communicate using the same transport protocol. Clients, 
servers, Interchanges, and Names Servers can be members of 
one or more communities; however, they can be members of 
only one domain. 


SLL NT eA TTT) 
Administrative Regions 


A network is made up of one or more administrative regions. Network 
objects are configured within administrative regions. Each 
administrative region contains: 
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Central Administration 


e an installation of the Network Manager 

o one or more Oracle Names Servers 

e one or more domains 

a one or more network services or database links 
e one or more clients 


Each administrative region contains one or more Oracle Names Servers. 
Names Servers are used to translate global service names into their 
network addresses. Although having just one Names Server per 
administrative region is technically allowed, at least two Names Servers 
per region are recommended to provide highly reliable access to the 
details of the network. 


A network can be administered with one of the following types of 
regions: 


e central administration (one administrative region) 
e delegated administration (several administrative regions) 


Every region must have a unique name. The region, although it contains 
domains, is defined to “reside” in one of the domains that it contains. 
The region name is formed by appending one of the domain names onto 
the end of the region name. For example, a region containing the 
US.ACME and UK.ACME domains could be called either 
region_name.US.ACME ot region_name.UK.ACME. A name outside that 
region, such as region_name.CA.ACME, would be rejected. (The 
Network Manager's validation feature would disallow an invalid region 
name.) 


A central administrative region has a single installation of the Network 
Manager. 


Central administration can use either the flat or hierarchical naming 
model. Figure 3-8 shows two alternative centralized administrative 
region configurations. 


Note: Most customers with small installations may prefer to 
use central administration with a flat naming model. Or, it 
might be more beneficial to your network to use Oracle. Names 
with the Dynamic Discovery Option. See the section "Choose 
Whether to Use the Dynamic Discovery Option” in Chapter 1 
for more information. 
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Figure 3-8 Two Centralized Administration Alternatives 


Each Names Server in an administrative region resolves address 
requests for that region. In the most common case of a single, central 
administrative region, all Names Servers contain identical data, and give 
identical results. 


As changes are made to network objects within a particular 
administrative region (such as adding or changing database or Names 
Server addresses) the network administrator refreshes the cache of the 
Oracle Names Servers using the Network Manager (or the Names 
Control Utility). Each of the Names Servers then gets a new copy of the 
relevant contents of the network definition database, making the data 
quickly available to all clients. 


Delegated Administration 


If an organization is diverse enough that central administration is not 
possible, or if the volume of data being maintained warrants 
decentralization, configuration and administration can be delegated to 
any number of sites. To delegate administrative regions, you must have 
a hierarchical naming model because each administrative region must 
control one or more different domains. 


Each administrative region includes an installation of the Network 
Manager. Each network definition created with the Network Manager 
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must include references to other administrative regions as discussed 
later in this section. 


In the case of multiple administrative regions, the network 
administrator uses the Network Manager to record the details of the 
local region, and Names Server addresses and domains of the root 
region, and any child regions (of the local region). 


Delegating Administrative Regions 
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Administrative regions can be “delegated” from the top of the hierarchy 
in any granularity down to the number of domains in the naming 
model. For example, a naming model with ten domains can have 
between one and ten administrative regions. The domain at the top of 
the hierarchy is known as the root domain. Similarly, the administrative 
region that encompasses the root domain is known as the root 
administrative region. The root defines the reference point within which 
the naming model and the administrative model function. 


All administrative regions other than the root are hierarchically 
delegated directly or indirectly from it. Figure 3 ~ 9 shows a network 
with five domains and three administrative regions: the ROOT, and two 
delegated regions (DR1, DR2). 


Note: The WORLD domain always appears in Network 
Manager. Because it is not used in hierarchical configurations, 
however, it is not shown in the following figures. 
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Figure 3-9 Delegated Administrative Regions 
Rules for Delegating: 


e The hierarchy of domains can be to any depth. The limit in 
delegating the naming model is a practical one, not a technical 
one. 


e An administrative region must encompass domains that have the 
same lineage, that is, they must either be siblings or share a 
common ancestor domain, without skipping a generation. This is 
only a concern if the naming model is hierarchical to at least three 
levels. 
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Figure 3-10 shows an illegal administrative region definition. 


Root Region 





Figure 3-10 Invalid Administrative Regions 


In this example, the DR2 region’s domains are not contiguous, 
that is, they do not share the same parent domain. (ASIA’s parent 
is ACME, and FRANCE’s parent is EUROPE.) Even though the 
EUROPE domain can be traced back to the common ancestor 
domain ACME, it is in a different administrative region than the 
FRANCE domain. If the DR1 and DR2 regions are combined into 
one region, it becomes valid because the EUROPE, ASIA, and 
FRANCE domains now all share a common ancestor 
domain-——ACME. 


The infrastructure required to support the root region and delegated 
regions is discussed in the next two sections. 


Oracle Names Administrator’s Guide 


The Root Administrative Region 


The root administrative region has a special role in the Oracle Names 
system. Hierarchically, it is the common thread among all delegated 
administrative regions. Additionally, it is where all backbone data is 
maintained. 


The root administrative region requires: 


* network data—The root administrative region is the “owner” of 
the network, or backbone data. The network data includes: 


~ communities—The set of protocol-based communities 
defining how clients and servers communicate. 


— Interchanges—-The set of MultiProtocol Interchanges and the 
communities they connect. 


- Names Servers in the root region—The complete details of 
the Names Servers in the root administrative region. 


The communities, and the Interchanges connecting them, and the 
Names Servers in the root region define the limits of the network, 


All changes to the network are made in the root administrative 
region through Network Manager. These changes must also be 
made in every delegated administrative region. 


e Root administrative region infrastructure data—The same data 
that is required for every administrative region: 


~ Domains—The domains administered in this region. This is 
always at least the root domain, and can include other 
domains. 


+ Delegated administrative region Names Servers ~ The domains 
and Names Server addresses in any direct child regions of the 
root. 


e Data definitions for the root region — all of the database service 
names, database links, aliases, and client profiles associated with 
the root administrative region. 


' Data does not exist within the root domain (ROOT) itself. If the 
root administrative region contains only the root domain, then 
this region will have no database service names, database link 
names, or aliases. However, if the root administrative region 
contains other domains, then data can exist in the other domains. 
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Delegated Administrative Regions Below Root 


All administrative regions below the root are considered delegated 
administrative regions. Each delegated region requires: 


e A copy of the network data — Only the root administrative region 
can change the backbone data, but all administrative regions must 
have a copy. Network (also called “backbone”) data includes: 


— all communities in the network 
— all MultiProtocol Interchanges in the network 
— addresses of Names Servers in the root administrative region 


Every delegated administrative region needs to have the 
addresses of the Names Servers in the root region. Having this 
data allows Names Servers in delegated regions to contact any 
other region (through the root region). 


© The domains and Names Server addresses in its own (local) 
administrative region. 


+ Further delegated administrative regions—The domains and 
Names Server addresses in any of this administrative region’s 
child regions. Delegating more than one layer of regions below 
the root region is rare. 


o The data definitions—All of the database service names, database 
links, aliases, and client profiles for all of the domains in this local 
(delegated) administrative region. 


Communicating Changes to Administrators of Delegated Regions 
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Ina delegated administrative installation, changes to the initial network 
(backbone) data (which includes all communities and MultiProtocol 
Interchanges in the entire network, and all Names Servers in the root 
administrative region) need to be sent to all the administrators of the 
delegated regions. This should be done by the root region 
administrator. Working out a policy to handle the changes might 
include how much time in advance each administrator should be 
informed, when each administrator is expected to make the changes, 
and the details of the changes themselves. 


When the group of administrators is small, a simple format like an 
e-mail mailing list, or one or more telephone conference calls, or both 
informing all administrators of the changes should be sufficient. 
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Using the Oracle Network Manager to Define the Network 


The Oracle Network Manager is the “window” into the contents of the 
administrative region. Refer to the Oracle Network Manager 
Administrator's Guide for information on how to create a network 
definition. You use the Network Manager to configure: 


the network data - The definition of the communities and 
MultiProtocol Interchanges in the network, and all Names Servers 
in the root administrative region. (This is sometimes referred to as 
“backbone data.”) 


the administrative regions and their domains - The division of 
configuration into one Network Manager installation per region. 
The simplest and most common case is one administrative region 
with one domain (a flat naming model), although one 
administrative region with many domains, or multiple 
administrative regions, is also possible. 


the Oracle Names Servers - Within each region, the specifics of 
each of the Oracle Names Servers are also defined. Names Server 
specifics include the network node and addresses it runs on, and 
various startup parameters affecting how it operates. 


network objects in the local administrative region - The definition 
of database services, database links, and any aliases is also done 
through the Network Manager. 


For a given network, all of these objects are stored together in the 
Network Manager network definition database. In a network without 
Oracle Names, the network definition can be saved to either a database 
or an operating-system file; however, with Oracle Names, the network 
definition must be saved in a database. 


How Names are Resolved for a Client/Server Connection in a Central Region 


Role of the Client 


The sequence of steps in name resolution is very straightforward in the 
single, central administrative region configuration. 


The client is the software that requests the name to be resolved. The 


user, 


name itself typically comes from the user’s application, or the actual 
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Ina client-server connection, the client is obvious. In a distributed 
database, each database link is treated as a separate connection identical 
to a client-server connection. In general, the initiating server is 
considered the “client” for each outgoing database link. 


When the name is successfully resolved, the client uses it to connect to 
the intended destination. All interaction with the Names Server and use 
of the results is transparent to the user. Only an unsuccessful attempt is 
seen by the client or user. 


Role of the Names Server 


The Names Server has a single purpose: to resolve, or assist in resolving, 
aclient-initiated name request. It interprets the request, then looks up 
the name in its cache, or it calls a Names Server in another region. The 
response or error conditions are passed back to the client. 


Figure 3 ~ 11 shows a client requesting access to a Names Server named 
POULTRY and a Names Server providing the answer. A flat naming 
model is assumed. 


Note: The service name is the same as the global object name. 
For example, a global database name might be 
POULTRY.WORLD, which is also the service name. 


Oracle Names 
Server 





Client ` 
Application POULTRY. WORLD 


Figure 3-11 Client-Server Connection 
The sequence of events is as follows: 


1. The client application issues a connection request to SQL*Net of the 
form: 


sqlplus scott/tiger@POULTRY 
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where POULTRY is a database service name defined in the Oracle 
Names Server. 

SQL*Net determines from the client configuration in the 
SQLNET.ORA file that the client’s default domain is WORLD and 


the preferred Names Server is the one shown. SQL*Net sends the 
Names Server a request to resolve the name POULTRY.WORLD. 


2. The Names Server receives the request, looks it up in the cache, then 
sends the response back to the client. 

3. The client receives the answer and substitutes the address in place of 
the initial name POULTRY. 


4. The client contacts POULTRY and establishes a standard SQL*Net 
client-server connection. 


Only step 1 and the acknowledgement of Step 4 are seen by the user, 
unless an error occurs. 


For information about resolving a name across delegated administrative 
regions, see “How Names are Resolved in Delegated Administrative 
Regions”, in Appendix C. 


ANT LLL 
How Names are Resolved for a Distributed Database Connection 


in a Central Region 


Name resolution in a distributed database in the single administrative 
region configuration is similar to names resolution in a decentralized 
administrative region. The global database link name must be the same 
as the global database name. (Refer to the section Distributed Database 
Management” in Understanding SQL*Net for more information on how 
database links are resolved. 
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SELECT OBJECT 
FROM RUN@JERRY 
WHERE OBJECT LIKE '%STICK%' 


OP 
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Figure 3-12 Distributed Database Connection 
The sequence of events is as follows: 


1. Server TOM receives the SQL statement shown and checks its data 
dictionary for a private or public database link called JERRY. When 
it does not find one, SOL*Net determines from the client 
configuration in the SQLNET.ORA file that the client’s default 
domain is WORLD and the preferred Names Server is the one 
shown. SQL*Net then sends the Names Server a request to resolve 
the database link name JERRY.WORLD. 


2. The Names Server receives the request, looks it up in the cache, then 
sends the response back to the server TOM. 


3. Server TOM receives the answer and substitutes the response in 
place of the initial name. 


4. Server TOM contacts server JERRY and establishes a standard 
SQL*Net distributed database connection. 
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CHAPTER 


Planning for Oracle 
Names 


T his chapter describes the issues to consider before installing and 
configuring Oracle Names, including: 


e choosing a naming model (not applicable with DDO) 

e defining administrative regions (not applicable with DDO) 
+ determining the number of Names Servers required 

e selecting Names Server nodes 


Read this chapter before installing Oracle Names. Be sure to make all 
planning decisions before installing Oracle Names. 


= Note: There may be other considerations specific to your 
LE operating system and platform. See your platform-specific 
OS Doe manuals for details. 
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Before Installing Names Servers 





or 
SQLNet 











The details of this chapter may require knowledge from elsewhere in 
this and other Oracle manuals. 


Refer to Understanding SQL*Net for more information on SQL*Net. 
Refer to the Oracle7 Server Administrator's Guide, and Oracle7 Server 
Concepts for information on using global object names in distributed 
databases. 


Pesca nS SOE Ee aN] 


Choosing a Naming Model 


Note: DDO always uses a flat naming model. 


The most fundamental decision to make before installing Oracle Names 
is what naming model to use. 


There are two types of naming models to choose from: 
e flat naming model 
e hierarchical naming model 


See Chapter 3, “Oracle Names Architecture”, for detailed descriptions of 
the flat naming and hierarchical models. 


Consider Existing Standards 
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Many companies already have global naming standards for their PC 
LANs, large hosts, or mail systems. If such policies exist, you can use 
them as the basis for the Oracle Names naming model. Using the same 
structure leverages the investment in the education users already have 
with global names. 


For example, many companies with TCP/IP networks use the Domain 
Name Service (DNS) model for communication on the worldwide 
Internet. In this model, all naming models are hierarchical from a set of 
base domains such as: 


e COM - commercial organizations 
e EDU - educational institutions 

e MIL- military 

e ORG - organizations 


Individual companies are then assigned domains within which to build 
their naming model (for example, ACME.COM). To adapt any example 
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Anticipate Growth 


Know If You Are First 


in this book to the DNS Internet model, add a single high-level domain, 
such as COM (or other stem). 


For organizations which are on the Internet, and therefore already have 
one or more DNS domains, the sensible choice is to align their Oracle 
naming domains with their DNS domains. 


Try to anticipate the growth of the names in the system. A flat naming 
model may work well until you have several hundreds or thousands of 
names. At these volumes, a single administrator will be very busy 
coordinating changes and will likely be dealing with many duplicate 
name requests. Subdivisions into additional domains, or 
decentralization of administration reduces the frequency with which 
this problem occurs. 


If you are a division of a large corporation, be sure not to assume that 
you are the only Oracle Names installation in the company. Figure 4-1 
shows PET Corp, where the Pooch and Mutt divisions each 
independently installed Oracle Names. Subsequently, they both chose 
the domain names PET and DOG.PET for some of their names. 
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Figure 4-1 Merging Name Models 


At the PET company picnic, the two Oracle Names administrators met 
and decided to create one delegated region rather than two 
independent, centralized regions. The MUTT administrator would own 
the root data, and would rename his DOG.PET domain to PUPPET. 
Knowing about each other earlier, or anticipating the possibility of such 
an event, could have reduced the work involved. 


PS SESSE a 
Defining the Administrative Regions 
Note: Due to the fact that DDO only works with a single 
domain region this step is not applicable if you are going to use 
the DDO. 
The Oracle Names system can be divided into multiple cooperative 
administrative regions. Each region can be independently operated and 


maintained with a small amount of cross-referenced data. Specifically, 
all administrative regions must have a copy of all backbone data, which 


consists of the following: 
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e The communities. and Interchanges in the entire network. 


s addresses of all Names Servers in the root administrative region 
must be defined in each administrative region. 


For more information see Chapter 3, “Oracle Names Architecture” for a 
detailed description of administrative regions. 


Choosing the Administrative Model 


There are two basic choices when allocating administrative regions: a 
single, central administrative region or more than one administrative 
region. 


A region or administrative region is an organizational entity for 
administering SQL*Net network components. Each region includes one 
Network Manager, one or more domains, one or more Oracle Names 
servers, network object definitions, and a network definition. Central 
administration and the flat naming model (that is, all names within one 
domain) is the default. 


For delegated administration, you define each region and its child 
regions as region objects in the Network Manager. The highest level 
parent region is the root region from which all other regions are 
delegated. The root region always consists of the predefined root 
domain (the initial hierarchical reference point), and typically also 
includes, at least, the highest level organizational domain, for example, 
COM, EDU, MIL, or ORG (for commercial, educational, military, and 
organization domains). 


Establishing Administrative Policies 


An important part of running an Oracle Names installation is the 
planning and methods that all administrators must carry out. All 
installations need policies on how the following tasks are handled: 


e Name data requests -'How data gets into the Names Server. 


e Inclusion requirements - What data to allow, and not allow in the 
Server. 


e Names Server maintenance - What to do when a Names Server 
fails. 


Delegated administrative installations also require policies for handling 
the following: 


e Shared data changes—How to coordinate passing of information 
to delegated administrators when backbone data changes. 
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(Network data includes communities and MultiProtocol 
Interchanges in the entire network, and all Names Server 
addresses in the root region.) 


+ Administrative region requirements—The minimum 
requirements for allowing portions of the naming model to 
become delegated administrative regions. 


See Chapter 3 “Oracle Names Architecture” for a detailed description of 
administrative regions. 


Pia SEA 


Determining The Number of Names Servers 


Note: There can be no more than five well-known Names 
Servers when you use the DDO. 


Using a system like Oracle Names makes users dependent on access to 
the names it stores. If a system had a single Names Server, and that 
server were unavailable, no client-server applications in the network 
could communicate. It is therefore very important to ensure high 
availability of data in the network’s Names Servers. 


Two Names Servers Per Region 


Oracle recommends that each administrative region should have at least 
two Names Servers. If one Names Server is unavailable, clients will 
automatically forward requests to the other. The degree of availability 
this allows depends on the regularity of service each node provides. For 
example, imagine that the amount of time a Name Servers node is down 
for unscheduled reasons is 1%. (It is usually much less.) The likelihood 
that both would be down at the same time is then roughly .01%, or 1% 
of 1%. 


There is also an issue of network loading, or load balancing. Although 
any given Names Server is only engaged for a short period of time when 
a client initiates a connection, the goal is to keep name resolutions 
lightning fast. With a very large volume of clients, or applications 
requiring many connections, load balancing across multiple Names 
Servers can increase system performance. 


One Names Server Per Community 


It is strongly recommended that regions with multiple communities 
offer at least one Oracle Names Server per community. (Refer to the 
glossary for a definition of communities.)This can be either a single 


4-6 Oracle Names Administrator’s Guide 


Names Server between multiple communities, or separate Names 
Servers in each community. This is not a technical restriction—using a 
MultiProtocol Interchange, the client could connect to a Names Server in 
another community. However, this is presented as a strong 
recommendation to avoid name requests travelling through an 
Interchange to resolve a name. Connection time through an Interchange 
is commonly on the order of a few seconds rather than the milliseconds 
in which a name should be resolved. 


In multi-community installations, it is recommended that Names 
Servers be installed on nodes with MultiProtocol Interchanges between 
the communities. The benefit is that all clients in all communities the 
Names Server node is on can access it. The Interchange node is an 
obvious candidate because it always runs multiple protocols. 


Names Server Proximity to Clients 


In general, the closer data is to a client, the faster it is retrieved, and the 
less likely it will be made unavailable by network failures. Clients 
should be able to reliably get to at least one Names Server in less than a 
second, If they cannot, consider adding another Names Server to serve 
those clients 


For example, an installation with a single administrative region 
administered out of Hong Kong with three Names Servers, two in Hong 
Kong and one in Japan may provide fast, high availability to some 
Eastern countries but could leave offices elsewhere in the world subject 
to poor performance and network outages. Remember if the Names 
Server is unavailable, client connections are disabled. Installing 
additional Names Servers in the USA, Europe, and elsewhere would 
provide clients in those areas with more reliable name resolution. All 
Names Servers could still be maintained (with respect to names data 
and management) from the single administrative region in Hong Kong, 
but would be physically close to the clients. 


AER TTD 
Selecting Names Servers Nodes 


Note: If you have successfully installed the Oracle Names 
software you have already made this choice. 


An Oracle Names Server is portable software that runs on a variety of 
computer platforms. You can obtain specific platform and operating 
system availability information from your Oracle representative. In 
general, Oracle Names runs on: 


e A variety of UNIX and VAX/VMS minicomputers and 
workstations. 
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e Intel-based computers (PCs) running operating systems such as 
OS/2, NetWare, Windows NT, and UNIX. 


The computer does not have to be dedicated as an Oracle Names Server. 
In fact, Oracle Names typically requires relatively little CPU and 
memory to function. 


Your choice of computer to use as a Names Server should be based on: 


e Software availability—While Oracle Names runs on many 
operating systems, it does not run on all. As a shared resource, 
Oracle Names only needs to be on one type of operating system 
to serve all clients and servers. It does not have to be available on 
all of the operating systems you use. 


e Node availability and maintenance—A server that is monitored 
and maintained by a group assigned the task of maintaining the 
system is best. A failure on a corporate data center computer is 
more likely to be recognized and fixed quickly than if the 
computer is on an someone's desk. Data center computers are 
also more commonly backed up and diagnosed regularly. These 
criteria tend to favor UNIX, VMS, or PC LAN file server nodes, all 
of which are commonly maintained in a data center. 


e Community coverage—As stated above, in a multi-community 
SOL*Net network, choosing a MultiProtocol node as a Names 
Server minimizes the number of nodes that need to be installed 
for redundancy. There is no requirement that the Names Server 
run ona MultiProtocol node; it is a matter of minimizing 
administrative overhead for complete name service coverage. 


Note: Currently, you are required to have a Names Server in 
every community. In general, Oracle recommends that Names 
Servers in a multi-community network be placed on 
Interchange nodes, thereby minimizing the number of Names 
Servers required. 


e CPU availability—The node chosen must have adequate CPU, 
memory, and disk space available for an Oracle Names 
installation. Beyond the operating system and any other activity 
on the machine, Names must have the resources it needs to run. 
Installation on an old 386 PC, or a loaded-down UNIX server will 
not allow the system to perform optimally. 
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If the node you have chosen already has SQL*Net or an Interchange on 
it from a previous installation, the node should already be defined. You 
enter information such as the following on the Name Server property 
sheet in the Network Manager: 


e protocol-specific address information 
e Names Server password 
o log and trace file names 
You must enter the address information; however, all other values have 


defaults. If you have security concerns, it is always good practice to 
change the default password. 
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CHAPTER 


Setting Up and 
Running Oracle Names 
with the Dynamic 
Discovery Option 


T his chapter provides several scenarios that show how to set up and 
use Oracle Names version 2.0 with the Dynamic Discovery Option 
(DDO). 

Tf you are not certain whether to use the Dynamic Discovery Option, see 
“Choose Whether to Use the Dynamic Discovery Option” in Chapter 1. 


Upgrading to SQL*Net release 2.3 and Oracle Names 2.0 without the 
Dynamic Discovery Option is discussed in Chapter 6, “Configuring 
Oracle Names”. 


Setting Up and Running Oracle Names with the 5-1 
Dynamic Discovery Option 


STA 


Configuration Scenarios 


This chapter describes how to do the following: 


e Create a new network using DDO—create a completely new 
network using Oracle Names 2.0 and the Dynamic Discovery 
Option. 


+ Upgrade all components in an existing network—upgrade all 
the existing Oracle Names and SQL*Net components in your 
network to SOL*Net 2.3 and Oracle Names 2.0 using the Dynamic 
Discovery Option. 


+ Gradually upgrade an existing network—gradually upgrade an 
older SQL*Net network to use SQL*Net release 2.3 and the 
Dynamic Discovery Option. 


+ Upgrade from a Native Naming Adapter—gradually migrate a 
site which uses another naming service to use Oracle Names 2.0 
with the Dynamic Discovery Option. 


In addition, this chapter includes a section on non-default parameters. If 
your network configuration is not covered by of these scenarios, see 
Appendix B, “Complex Network Issues and DDO,” for instructions on 
other networks. 


Note: If you have a network that stays the same for long 
periods of time, whether large or small, converting the network 
to dynamic discovery may not be worth the effort. Also, 
administrators of networks that have MultiProtocol 
Interchanges, gateways, or Native Naming Adapters might find 
the Dynamic Discovery Option more troublesome to use than its 
benefits warrant. 


DSN Ie STS OUD SLO 


A Review of Network Components 
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In order for Oracle Names 2.0 to function correctly as a naming service, 
certain information needs to be accessible to certain components. When 
you configure and run a network with Oracle Names 2.0 and the 
Dynamic Discovery Option, there are three main network components 
that must be able to communicate and find each other: 


e Names Servers—The Names Servers on the network using DDO must 
know about each other. In a network using the DDO, each new 
Names Server finds other Names Servers at well-known Names 
Server addresses. 


Oracle Names Administrator’s Guide 


e Oracle7 Servers—Oracle7 Servers must know how to find a Names 
Server in order to register themselves automatically. If they are not 
registered automatically, they need to be defined in the network 
definition using Network Manager. 


e Clients—Clients on the network must know how to find all Names 


Servers. 
Dannan a NES 


Rules for Setting Up and Using the Dynamic Discovery Option 


` The following list of rules applies to all the given scenarios described in 
this chapter. Following these rules provides the smoothest transition to 
Oracle Names 2.0 with the DDO. 


e New Oracle Names Servers must also be defined in the network 
definition as long as there are SQL*Net 2.2 (or earlier) clients on 
the network that have not been upgraded. 


This is due to the fact that the network definition is the source of 
the NAMES.PREFERRED_SERVERS parameter in the 
SQLNET.ORA file which clients with earlier versions of SQL*Net 
use to locate the Names Servers. 


Since all Names Servers must read the network definition, and all 
Names Servers are defined in the network definition, Names 
Servers do not need well-known Names Servers to know about 
each other if a network definition exists 


All Names Servers should continue to use the network definition 
to get information for 7.2 (or earlier) databases whenever the 
~ connect data is modified. 


In this case there is no need for Dynamic Discovery. 


e New and upgraded Names Servers can use well-known 
addresses as long as the new well-known Names Servers are 
defined in the network definition using oranamesrvr0-4. 


Clients, databases, and listeners on an existing network already 
have a NAMES.PREFERRED_SERVERS defined in their 
SQLNET.ORA file enabling them to find all local Names Servers, 


regardless of whether they are using a well~known Names Server. 


These are configured addresses that are provided to Oracle 
Names clients, and SQL*Net clients and listeners. These addreses 
are also provided to other Names Servers in the network 
definition. 
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Before You Begin 


A TE 


e When all SOL*Net release 2.2 (or earlier) clients have been 
upgraded, the Names Server definitions can be dropped from the 
network definition. 


e When all databases and listeners in the region are upgraded to 
Oracle 7.3, their definition in the network definition can be 
dropped because services are now automatically registered. 


When the previous two items are true, the network definition and 
the NAMES.PREFERRED_SERVERS parameter can be dropped 
entirely. All of the Names Servers and all of the clients are now 
upgraded and the network definition is unnecessary in the 
Dynamic Discovery network. 


Before you begin using any of the following upgrade scenarios, the 
following must be true: 


+ a single region and a single community 
+ a protocol which supports well-known addresses 


These scenarios describe the TCP/IP protocol. If you need 
information on other protocols, see your platform-specific 
documentation. 


« single TCP (DNS) domain 


e site administrator chooses to use the Dynamic Discovery Option. 


Scenario 1: Create a New Network Using the Dynamic Discovery Option 


The following steps are brief guidelines for you to create and run your 
network using Oracle Names 2.0 with the Dynamic Discovery Option. 


No other configuration files are needed if you accept all default 
parameters. The only configuration file needed in a default setup is a 
LISTENER.ORA for every database, which is created automatically 
during installation. 


Install the Names Server. 


See your platform specific documentation for information on how to 
install the well-known Names Server. The default installation setup for 
the Names Server uses the Dynamic Discovery Option. 


Assign aliases to the nodes that will be well-known Names Servers. 
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You must provide an alias for each of the machines that will become 

a well-known Names Server. The required aliases are oranamesrvr0, 

| . oranamesrvr1, and so forth through oranamesrvr4. For TCP/IP 

: networks, the port number used by the well known Names Server is | 
1575. This port number is included in the SQL*Net 2.3 software so | 

| that all SQL*Net release 2.3 clients and services know it without any | 

action by you. 


@ Using NIS | 


i If Network Information Services (NIS) is used on the network, list | 
| the addresses of the well-known Names Servers in the host.byname l 
l map file. If there are slave NIS servers, do an explicit yppush to all | 
| the slaves. 


@ Without NIS | 


l TE NIS is not used, add an alias for each of the well-known Names l 
l Servers to the /etc/hosts file on every host file in the network. The 
content of the /etc/hosts file will look something like the following: 





| ipaddress howe. acme .com oranamesrvr0 | 
| ipaddress orr .acme. com oranamesrvrl 

| ipaddress roenick.acme.com oranamesrvr2 | 
| ipaddress gretzky.acme.com oranamesrvr3 | 
| ipaddress syoung .acme.com oranamesrvr4 i 


| The well-known address port number may vary depending on the | 
protocol in use in your network; refer to your platform-specific 
documentation for the specific port number used. 


| -Start the 2.0 Names Servers on nodes for which you created the YP 
| or NIS aliases. 


The NAMESCTL START command loads the Names Server into 

memory and tells it to begin executing. At startup, the Names Server 

loads its configuration, loads its data, then becomes available to 

answer requests. 
| 
i 
| 
i 
| 

i 


To start the Names Server, execute the following command: 
NAMESCTL START 


A message will indicate whether or not the Names Server was 
successfully started. 





' . Install and define databases and listeners. 


| Answer Yes when queried during the installation process whether 
to upgrade using the Dynamic Discovery Option. | 
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See the Oracle operating system-specific documentation for your 
platform. You may also want to refer to the following documents 
published by Oracle Corporation: 


e Oracle7 Server Concepts 
o -Oracle7 Server Administrator's Guide 


At this point the LISTENER.ORA file is created. At system startup, 
each Names Server loads all the Dynamic Discovery data for each 
service in the LISTENER.ORA file. This is the only default file which 
gets created during installation for each database server. 


re Attention: When installing SOL*Net you must execute the 


install_pnp script to be able to generate a LISTENER.ORA file. 
Execute the script in order to proceed. For more information on 
the install_pnp script see your platform-specific documentation. 


Check to see if the GLOBAL_DBNAME parameter is in your 
LISTENER.ORA file. It will look approximately like the following: 


GLOBAL_DBNAME=DBNAME. domain 


If you do not have the GLOBAL_DBNAME in your 
LISTENER.ORA file the listener will not be able to register with the 
Names Server. 


Start listeners using LSNRCTL. 
To start a network listener, execute the following command: 
LSNRCTL START 


When the listener starts, it registers itself and the services it listens 
for with the well-known Names Server. 


Install clients. 


See your platform-specific documentation for more information on 
how to install clients on your network. 


Test if the Names Servers have the databases defined. 


From any node on your network that has SQL*Net and NAMESCTL 
installed, enter the following NAMESCTL command: 


NAMESCTL> QUERY db_name 


At this point your network should be fully operational with the 
Dynamic Discovery Option so that you can start the database and use 
your network connections. 
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Attention: The Dynamic Discovery Option only works on 
KF nodes that use SQL*Net release 2.3. Services will not be 

automatically registered if SQL*Net release 2.3 is not used, and 

clients will not be able to find the well-known Names Server. 





Scenario 2: Upgrading All Components in an Existing Network 


The following steps are a guide for upgrading all network components 
to SQL*Net 2.3 and Oracle Names 2.0 using the Dynamic Discovery 
Option. 

This scenario is useful for networks that can upgrade all components 
from an existing SQL*Net version to SQL*Net 2.3 and Oracle Names 2.0 
with the Dynamic Discovery Option at one time. 


~ Shut down all database listeners. 


On all client and server nodes, use a text editor to remove the 
NAMES.PREFERRED_SERVERS parameter in the SQLNET.ORA 
file. 


Remove the NAMES.ORA file on all existing Names Server nodes. 


Your explicit path to NAMES.ORA is operating system~specific. On 
most UNIX systems NAMES.ORA exists in the following location: 


SORACLE_HOME/network/admin/names.ora 
Install Oracle Names 2.0 on the Names Server nodes. 


We recommend installing Oracle Names on at least two Names 
Servers to preserve a fault-tolerant network. 


Assign aliases to the nodes that will be well-known Names Servers. 


You must provide an alias for each of the machines that will become 
a well-known Names Server. The required aliases are oranamesrvr0, 
oranamesrvr1, and so forth through oranamesrvr4. For TCP/IP 
networks, the port number used by the well known Names Server is 
1575. This port number is included in the SQL"Net 2.3 software so 
that all SQL*Net release 2.3 clients and services know it without any 
action by you. 


E Using NIS 


If Network Information Services (NIS) is used on the network, list 
the addresses of the well-known Names Servers in the host.byname 
map file. If there are slave NIS servers, do an explicit yppush to all 
the slaves. 
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m Without NIS 


If NIS is not used, add an alias for each of the well-known Names 
Servers to the /etc/hosts file on every host file in the network. The 
content of the /etc/hosts file will look something like the following: 


ipaddress howe.acme.com oranamesrvr0 
ipaddress orr.acme.com oranamesrvrl 
ipaddress roenick,acme.com oranamesrvr2 
ipaddress gretzky.acme.com oranamesrvr3 
ipaddress syoung.acme.com oranamesrvr4 


Note: The well-known address port number may vary 
depending on the protocol in use in your network; refer to your 
platform-specific documentation for the specific port number 
used, 


Start the 2.0 Names Servers on nodes for which you created YP or 
NIS aliases. 


The NAMESCTL START command loads the Names Server into 
memory and tells it to begin executing. At startup time, the Names 
Server loads its configuration, loads its data, then becomes available 
to answer requests. 


To start the Names Server, execute the following command: 


NAMESCTL> START 


A message will indicate whether or not the Names Server was 
successfully started. 
Upgrade all listeners to SQL*Net 2.3 and databases to Oracle7.3. 


Answer Yes when queried during the installation process whether 
to upgrade using the Dynamic Discovery Option. 


At this point the LISTENER.ORA file will be created. This file 
contains all the Dynamic Discovery data for each service. 


F Attention: When installing SQL*Net you must execute the 


install_pnp script to be able to generate a LISTENER.ORA file. 
Execute this script in order to proceed. See your 
platform-specific documentation for more information on using 
or obtaining the install_pnp script. 


Check to see if the GLOBAL_DBNAME parameter is in your 
LISTENER.ORA file. It will look approximately like the following: 


GLOBAL_DBNAME=DBNAME. domain 
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If you do not have the GLOBAL_DBNAME in your 
LISTENER.ORA file the listener will not be able to register with the 
Names Server. 


Start listeners using LSNRCTL. 
To start a network listener, execute the following command: 
LSNRCTL START 


When the listener starts, it registers itself and the services it listens 
for with the well-known Names Server. 


Upgrade all clients on the network. 
Each client application should now be upgraded to run SQL*Net 2.3 


At this point all of the components in your network should be fully 
configured to run Oracle Names 2.0 with the Dynamic Discovery 
Option. 

Test whether applications can successfully connect to an Oracle Names 
Server from a SQL*Net client. Execute a SQLPlus application, such as 
sqlplus username/password@service_names, where service_name is the 
database name that has just been registered. If you cannot connect, most 
likely you will receive the error ORA-12154. This usually indicates that 
the client cannot find the Names Server. Refer to the trace files or error 
message log files to find details. 


eae EE RO 
Scenario 3: Gradually Upgrading an Existing Network 


This scenario is most useful to a site that cannot upgrade everything at 
once, but want to upgrade various components to the Dynamic 
Discovery Option in an orderly fashion. 


This scenario takes you through an upgrade where there are three 
existing Names Servers in a network. All of the servers are upgrading to 
SQL*Net 2.3 and Oracle Names 2.0, but at this time only two are 
becoming well-known Names Servers using the Dynamic Discovery 
Option. The third Names Server will not use the DDO. 


In this case, the network will maintain some SQL*Net 2.2 clients and 
some SQL*Net 2.3 clients. 


Upgrade all Names Servers to Oracle Names 2.0. 


It is important that all Names Servers be upgraded to Oracle Names 
2.0 so that they can replicate their registration information. 


Assign aliases to the nodes that will be well-known Names Servers, 
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You must provide an alias for each of the machines that will become 
a well-known Names Server. The required aliases are oranamesrvr0, 
oranamesrvr1, and so forth through oranamesrvr4. For TCP/IP 
networks, the port number used by the well known Names Server is 
1575. This port number is included in the SQL*Net 2.3 software so 
that all SOL*Net release 2.3 clients and services know it without any 
action by you. 


WE Using NIS 


If Network Information Services (NIS) is used on the network, list 
the addresses of the well-known Names Servers in the host.byname 
map file. If there are slave NIS servers, do an explicit yppush to all 
the slaves. 


m Without NIS 


TENIS is not used, add an alias for each of the well-known Names 
Servers to the /etc/hosts file on every host file in the network. The 
content of the /etc/hosts file will look something like the following: 


ipaddress howe acme .com oranamesrvrd 
ipaddress orr.acme.com oranamesrvrl 
ipaddress roenick.acme.com oranamesrvr2 
ipaddress gretzky.acme.com oranamesrvr3 
ipaddress syoung.acme.com oranamesrvr4 


Note: The well-known address port number may vary 
depending on the protocol in use in your network; refer to your 
platform-specific documentation for the specific port number 
used.” i 


The newly migrated well-known Names Servers need to be defined 
in the network definition. Using Network Manager, change the 
address of two of the newly upgraded Names Servers to be 
well-known addresses. To do this, create new nodes names 

- oranamesrvr0 and oranamesrvr1. Edit the property sheets of the 
two of the Names Servers so that they are on these nodes, using port 
1575. 


For example, the previously existing network definition for the two 
servers might have looked like the following: 


(address= (protocol=tcp) (host=gretzky) (Port=1529)) 
(address=(protocol=tcp) (host=howe) (Port=15239)) 


The new well-known address definition that you update using 
: Network Manager must look like the following: 


(address=(protocol=tcp) (host=oranamesrvr0) {port=1575) ) 
(address= (protocol=tcp) {host=oranamesrvr1} (port=1575) } 
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Start the well-known Names Servers on nodes for which you 
created YP or NIS aliases. 


The NAMESCTL START command loads the Names Server into 
memory and tells it to begin executing. At startup time, the Names 
Server loads its configuration, loads its data, then becomes available 
to answer requests. 


To start the Names Server, execute the following command: 
NAMESCTL START 


A message will indicate whether or not the Names Server was 
successfully started. 


Upgrade all desired listeners to SOL*Net 2.3 and databases to 
Oracle7.3, 


Use Network Manager to remove each database that you choose to 
upgrade from the old network definition. This is necessary because 
all Oracle7.3 databases will automatically register themselves with a 
well-known Names Server. The database name automatically goes 
into the LISTENER.ORA file that is being created when that 
database is upgraded. When the listener starts, it registers the 
database name with the well-known Names Server. 


During the upgrade process, answer Yes” when queried whether to 
upgrade using the Dynamic Discovery Option. 


At this point the LISTENER.ORA file will be created. This file 
contains all the Dynamic Discovery data for each database. 


ee Attention: When installing SQL*Net you must execute the 


install_pnp script to be able to generate a LISTENER.ORA file. 
Execute this script in order to proceed. See your 
platform-specific documentation for more information on using 
or obtaining the install_pnp script. 


Check to see if the GLOBAL_DBNAME parameter is in your 
LISTENER.ORA file. It will look approximately like the following: 


GLOBAL_DBNAME=DBNAME. domain 


If you do not have the GLOBAL_DBNAME in your 
LISTENER.ORA file the listener will not be able to register with the 
Names Server. 


Start listeners using LSNRCTL. 
To start a network listener, execute the following command: 


LSNRCTL START 
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When the listener starts, it registers itself and the services it listens 
for with the well-known Names Server. 


Upgrade the desired clients to SQL*Net 2.3. 


At this point you have the option of removing the 
NAMES.PREFERRED_SERVERS parameter in the SQLNET.ORA 
file for all SQL*Net 2.3 clients. We recommend that you keep this 
line in the SQLNET.ORA file. In case both well-known Names 
Servers are not available, those clients can still find the other Names 
Server even though it is not a well-known Names Server. 


This is an issue of reliability versus maintenance and distribution, 
and should be decided by individual administrators for each 
individual network. 


Start all databases and listeners that have been upgraded. 


Note: SQL*Net 2.2 clients can be configured to use the 
well-known Names Servers. Simply define the new 
well-known Names Servers on the 

NAMES.PREFFERED_ SERVERS parameter in the network 
definition using Network Manager. 


Generate new configuration files. Distribute the SQLNET.ORA files that 
include the new Names Server addresses to all of the clients on the 
network. 


Note: All three Names Servers should be included in the list of 
NAMES.PREFFERED_SERVERS in the SQLNET.ORA file. 


Although it has been upgraded to Oracle Names 2.0, the third Names 
Server does not need the NAMES.PREFFERED, SERVERS in the 
SQLNET.ORA file be edited. 


At this point all of the components you have chosen to upgrade in your 
network should be fully.configured to run Oracle Names 2.0 with the 
Dynamic Discovery Option. 


Test whether applications can successfully connect to an Oracle Names 
Server from a SQL*Net client. Execute a SQLPlus application, such as 
sqlplus username/password@service_names, where service_name is the 
database name that has just been registered. If you cannot connect, most 
likely you will receive the error ORA-12154. This usually indicates that 
the client cannot find the Names Server. Refer to the trace files or error 
message log files to find details. 
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Scenario 4: Upgrading from a Native Naming Adapter 


This scenario is based on gradually upgrading from a native naming 
adapter to Oracle Names 2.0 with the Dynamic Discovery Option. 


Set all clients NAMES.DIRECTORY_PATH parameter in the 
SQLNET.ORA file to include both Oracle Names 2.0 and other 
adapters such as NIS. 


The default setting of the NAMES.DIRECTORY_PATH parameter in 
the SQLNET.ORA file will be in the following order: 


e TNSNAMES.ORA 
e Oracle Names (ONAMES) 
e other naming adapter (NIS) 


You can arrange the order of the names this parameter according to 
your preference. For non—default settings, for example, if you want 
to use DDO, you must change the file so that ONAMES will be first. 


To do this, use the SQLNET.ORA Editor to set the parameter as 
follows: 


NAMES . DIRECTORY_PATH= (ONAMES, NIS, TNSNAMES.ORA) 


When the NAMES.DIRECTORY_PATH is set as shown above, the 
client will attempt to use a Names Server before using the NIS 
naming adapter. 


When a database listener is upgraded to Oracle 7.3, its definition can 
be dropped from the native naming adapter so that it can be 
automatically registered by the database and listener. 


1S Attention: Databases should not be defined in both Oracle 
Names 2.0 and the native naming adapter. 


When all databases and listeners are upgraded to Oracle 7.3 and 
started to automatically register, the entire definition of the other 
native naming adapter can be dropped and the 
NAMES.DIRECTORY_PATH parameter in SQLNET.ORA can just 
be Oracle Names. 


DERS ESSES 
Non-default Parameters 


In a Dynamic Discovery environment in which all default parameters 
are accepted, you do not need to.have any configuration files except the 
LISTENER.ORA for each listener node created during installation. 
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However, there may be times when some additional configuration files 
are needed. There are two major reasons you may need other 
configuration files: 


e to add optional parameters to a SQLNET.ORA file 


e to add elements to your network that cannot register themselves 
with the well-known Names Servers 


> If you have a lot of non—default parameters to add, and 
especially if you want to define a number of objects that cannot 
Decision self-register, you may want to reconsider whether the Dynamic 
Discovery Option is appropriate for your network. 


How to Create a SQLNET.ORA File 


There are two ways to create a SQLNET.ORA file. Choose the method 
that best fits your situation. 


e If you want to create a SQLNET.ORA file that is the same for 
many clients, you may want to use Oracle Network Manager to 
create a network definition that includes a description of one or 
more client profiles. Generate configuration files from that 
definition, and transfer the configuration files to the appropriate 
nodes. This method is most useful if you can use an identical 
SQLNET.ORA file for many clients, or if you need to use Network 
Manager to add other objects to the network definition. For 
instructions on how to use Network Manager, see the Oracle 
Network Manager Administrator's Guide. 


e If you want to create SQLNET.ORA files for just a few clients, or if 
each client’s SQLNET.ORA file contains unique values, use the 
SQLNET.ORA Editor, part of the Client Status Monitor, to create a 
SQLNET.ORA file with the specific parameters needed. 


If you need more information, please see Oracle Network Products 
Troubleshooting Guide. 


Parameters in a SOLNET.ORA File 
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A SQLNET.ORA file may contain a number of optional parameters. 
Most of the parameters control the behavior of clients. There are also 
some parameters that control servers, the Names Control Utility, and the 
TNSPING Utility. 


All the SQLNET.ORA parameters are described in Understanding 
SQL*Net. This section describes the parameters you are most likely to 
want to include when using DDO. 
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Dead Connection 
Detection 


Logging and Tracing 
Parameters 


Dedicated Server 


Secure Network 
Services Parameters 


Disable Out of Band 
Breaks 


Default Domains 


Preferred Names 
Servers 


Note: Unless otherwise noted, these parameters can be added 
to an existing SQLNET.ORA file using the SQLNET.ORA Editor 
or Network Manager. 


Add this parameter to request SQL*Net to send a periodic probe to 
detect dead connections. A value of 10 (minutes) is recommended. 


You can set optional tracing and logging parameters for clients and 
servers in the SQLNET.ORA file. You can also set tracing parameters for 
the Names Control Utility and TNSPING. Use the SQLNET.ORA Editor 
for client and TNSPING parameters. Parameters for the server and the 
Names Control Utility must be added manually. 


Set this optional parameter to ON if you want to request a dedicated 
Names Server process from a server configured as a multi-threaded 
Names Server. 


If Secure Network Services is installed in your network, add parameters 
to request encryption, checksum, and authentication services. Use the 
SQLNET.ORA Editor to add them to the client side. Add them manually 
or with Network Manager for the Names Server. 


If you want to disable out of band breaks, add this parameter, set to ON. 
Out of band breaks are the default, unless there is an Interchange on the 
network, 


If the naming convention in your network includes a domain, you can 
enable applications to request connections to servers without including 
the domain in the request by adding this parameter with the domain as 
the value. 


Note: If you use Network Manager to create a SQLNET.ORA 
file, this parameter is included automatically, with .WORLD as 
the domain by default. If there is no domain in your network, 
use a text editor to delete this parameter in the SQLNET.ORA. 
file before distributing it to individual clients. 


You may want to have some of your clients contact one particular 
Names Server rather than another. In a Dynamic Discovery network all 
clients contact the Names Server on the node with the alias 
oranameserver0 first by default. To avoid bottlenecks, or to have the 
client contact the Names Server that is geographically closest, you may 
want to add this parameter to the SQLNET.ORA file. This concept is 
called network load balancing. See the following section for more details. 
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Network Load Balancing 


If your network covers a wide geographic area, or if you want to balance 
the load among the Names Servers, you can add a parameter to the 
SOLNET.ORA file on the clients so that they contact a specific Names 
Server first. That parameter is: 


NAMES . PREFERRED_SERVERS= (names_server_address)... 


For example, suppose you have a network with a well known Names 
Server given the alias oranamesrvr0 in New York and another with the 
alias oranamesrvr1 in London. You might want your clients in Europe to 
contact the Names Server in London first. For this to happen, every 
European client would need a SQLNET.ORA file with the following line: 


NAMES . PREFERRED_SERVERS= 

(ADDRESS_LIST= (ADDRESS= 
(PROTOCOL=TCP) 
(HOST=ORANAMESRVR1 ) 
(PORT=1575) ) 

(ADDRESS= 

(PROTOCOL=TCP) 
(HOST=ORANAMESRVRO) 
{PORT=1575) )) 
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Configuring 
Oracle Names 


T his chapter describes how to configure a network that uses Oracle 
Names. If you are using Oracle Names and the Dynamic Discovery 
Option, you may not need to configure your system at all. See Chapters 
1, 2 and 5 for more information. 


Also included in this chapter is a section on configuration parameters 
you can use with the Oracle Names Server once your configuration is 
complete. 


This chapter discusses configuration issues in the following order: 
e How to use Network Manager 
e Defining a Names Server 
« Defining a client profile 


° Defining global database links 
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Using Network Manager 


Oracle Network Manager is a tool that assists you in creating the 
configuration files needed for Oracle networking products. 


Network Manager allows information that is used across your network 
in several files to be enteréd only once, and allows changes in 
configuration data for one component to “ripple through” and cause 
changes in other related component information. Network Manager also 
enables you to use control commands in Oracle Names Control Utility 
(NAMESCTL). 


New to Network Manager is the ability to toggle the Dynamic Discovery 
Option on or off for individual listeners and Names Servers, and to 
include a global database name in the LISTENER.ORA file. 





Defining Network Objects With Network Manager 


There are three major steps to configuring a network using Oracle 
Network Manager. 


1. Create a network definition using Network Manager property 
sheets. 


2. Generate network component configuration files using the 
GENERATE command in Network Manager. 


3, Distribute the configuration files to the appropriate nodes on the 
network. 


These procedures are all described in detail in the Oracle Network 
Manager Administrator's Guide. 


annann CONST aL 
Defining a Names Server 


This section briefly covers how to define a Names Server using Network 
Manager. If you want more information, see Oracle Network Manager 
Administrator's Guide. 
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What Can be Defined In a Names Server 


The following items can be defined in a Names Server using Network 
Manager: 


e Name of actual Names Server—creates a service name for the 
Names Server. 


If you have more than one Names Server ina domain, each must 
have a unique name. 


Node 


Oracle recommends that if more than one community exists in the 
network, a Names Server should be placed on the same nodes as 
the MultiProtocol Interchange so that there is a Names Server 
available in every community. 


Password—creates a password if you want to require a password 
of anyone who wishes to manipulate the Name Server. 


Disable Dynamic Discovery—enables/ disables DDO. 


If you do not want this Names Server to use the DDO, you must 
select OFF. The default is for DDO to be ON. 


Note: Even if you do not select this check box, and thus leave 
DDO on, the Names Server must be specially configured to act 
as a well-known Names Server in a DDO network. This 
configuration must be done manually. See Chapter 5, “Setting 
Up and Running Oracle Names with the Dynamic Discovery 
Option”. 


Tuning—sets timing parameters for the Names Server. 
Address—creates an address for the Names Server. 
Logging—changes any of the logging parameters. 


SNMP—enables the Names Server to be monitored using Oracle 
SNMP Support. You can enter parameters to control the Names 
Server subagent that is used if Oracle SNMP Support is desired. 


How to Define a Names Server 


Your next step in configuring your network is defining your Names 
Server. 


See the Oracle Network Manager Administrator's Guide for information on 
how to define a Names Server. 
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Oracle Names Server Configuration Parameters 


This section describes all the configurable parameters that control how 
Oracle Names Servers operate. These parameters are located in the 
configuration file NAMES.ORA. 


You can control all the parameters for the administrative region the 
Names Server is in by using Oracle Network Manager. These 
configuration parameters are either read directly from the network 
definition database by the Names Server itself, or are read by the client 
or NAMESCTL, as appropriate. 


You typically enter and maintain most of these parameters by using 
Oracle Network Manager, which places them in the configuration files 
that it generates. 


The configuration files should not be manually edited. All other 
parameters, including the NAMESCTL parameters, must be added 
manually. Also, you can only edit configuration files that were 
generated by Network Manager. 


Names Server Parameters 


names.cache_checkpoint_ 


file 


names.cache_checkpoint_, 
interval 


The following, which appear in the NAMES.ORA file, are valid 
parameters for a Names Server. 





Specifies the name of the operating system file to which the Names 
Server writes its checkpoint file. See the Oracle operating 
system-specific manual for your platform for filename restrictions. 


Status: optional 

Type: text string 

Source: Network Manager enterable field 
Default value: ckpcch.ora 

Valid in File: NAMES.ORA 


names.cache_checkpoint_file = filename 





Indicates the interval at which a Names Server writes a checkpoint of its 
stored data to the checkpoint file. 


Each Names Server can periodically write its cached data to a file to 
protect against startup failures. When the Names Server cannot contact 
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the Network Manager database, it starts from the checkpoint file. The 
default value is 0, or no checkpointing. 





Status: optional 

Type: number (time in seconds) 

Source: Network Manager enterable field 
Default value: 0 l 
Valid in File: NAMES.ORA | 
Minimum value: 10 | 
Maximum value: 259200 (3 days) / 
Special value: 0 (disabled) | 


names .cache_checkpoint interval = seconds | 
| 





names.log_directory Indicates the name of the directory where the log file for Names Server l 
operational events are written. For details on logging see the Oracle f 
Network Products Troubleshooting Guide. For the default name of this file 
on your system see the Oracle operating system-specific manual for 
your platform. 


Status: optional 

Type: text string l 
Source: Network Manager enterable field l 
Default value: platform specific | 
Valid in File: NAMES.ORA | 


names. log directory = complete_directory_name 
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names.log_file 


names.log_stats_interval 





Indicates the name of the output file to which Names Server operational 
events are written. For details on logging see the Oracle Network Products 
Troubleshooting Guide. 


The file name extension is always log. Do not enter an extension in the 
Network Manager field for this parameter. 


Status: optional 

Type: text string 

Source: Network Manager enterable field 
Default value: names 

Valid in File: NAMES.ORA 


names.log_file = filename 





Specifies the number of seconds between statistical entries in the log file. 


Status: mandatory 

Type: number (time in seconds) 

Source: Network Manager enterable field 
Default value: 0 (0 = OFF) 

Valid in File: NAMES.ORA 

Minimum Value: 10 (least possible ON value) 
Maximum Value: none 


names.log_stats_interval = seconds 
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names.max_open_ 
connections 


names.reset_stats_interval 





Specifies the number of connections that the Names Server can have 
open at any given time. The value is generated automatically by 
Network Manager as the value 10 or the sum of one connection for 


listening, five for clients, plus one for each foreign domain defined in the 


local administrative region, whichever is greater. 


The calculated value is acceptable for most installations. 


Status: 

Type: 

Source: 

Default value: 
Valid in File: 
Minimum Value: 
Maximum Value: 


optional 

number 

Generated by Network Manager 
Calculated based on entered data 
NAMES.ORA 

2 

64 


names. max open connections = number 





Specifies the number of seconds during which the statistics collected by 
the Names Servers should accumulate. At the frequency specified, they 
are reset to zero. The default value of 0 means never reset statistics. 


Status: 

Type: 

Source: 

Default value: 
Valid in File: 
Minimum Value: 
Maximum Value: 
Special Value: 


mandatory 

number (time in seconds) 
Network Manager enterable field 
0 

NAMES.ORA 

10 

none 

0 (never reset) 


names.reset_stats_interval = seconds 
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names.server_name 


names.trace_directory 


names.trace_file 





Each Names Server is uniquely identified by a name. All configuration 
references to a particular Names Server use this name. 


Status: mandatory 

Type: text string 

Source: Network Manager enterable field 
Default value: NameServer.domain_name 

Valid in File: NAMES.ORA 


names.server_name = valid_string 





Indicates the name of the directory to which trace files from a Names 
Server trace session are written. For details on tracing, see the Oracle 
Network Products Troubleshooting Guide. 


Status: optional 

Type: text string 

Source: Network Manager enterable field 
Default value: platform specific (for example, names) 
Valid in File: NAMES.ORA 


names.trace_directory = complete_directory_name 





Indicates the name of the output file from a Names Server trace session. 
For details on tracing see the Oracle Network Products Troubleshooting 
Guide. 


The filename extension is always „trc, Do not enter an extension in the 
Network Manager field for this parameter. 


Status: optional 

Type: text string 

Source: Network Manager list 
Default value: names 

Valid in File: NAMES.ORA 


names.trace_file = filename 
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names.trace_level 


names.trace_unique 





Indicates the level at which the Names Server is to be traced. See the 
Oracle Network Products Troubleshooting Guide for details on how to 
initiate tracing. 


Status: optional 

Type: text string 

Source: Network Manager list 
Default value: OFF 

Valid in File: NAMES,.ORA 


names.trace_level = [OFF|USER|ADMIN] 





Indicates whether each trace file has a unique name, allowing multiple 
trace files to coexist. If the value is set to ON, a process identifier is 
appended to the name of each trace file generated. For details on tracing, 
see the Oracle Network Products Troubleshooting Guide. 


Status: optional 

Type: text string 

Source: Network Manager list 
Default value: OFF 

Valid in File: NAMES.ORA 


names.trace_unique = ON 
names.trace_file = names_05.tre 
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Sample Names Server Configuration File—NAMES.ORA 


Each Names Server in the network requires an individual configuration 
file called NAMES.ORA. This file contains control parameters for the 
Names Server and points the Names Server to the database where the 
network definition is stored. 


The following is an example of a NAMES.ORA configuration file: 


names.server_name = NameServer.us.oracle.com 
names.admin_region = (REGION= 
{NAME= LOCAL_REGION.world) 
(TYPE= ROSDB) 
(USERID= NETADMIN) 
(PASSWORD= netadmin) 
DESCRIPTION= 
(ADDRESS_LIST= 
({ADDRESS= 
(COMMUNITY=TCPCOM.us.oracle.com) 
{PROTOCOL=TCP) l 
(Host=deer.us.oracle.com) 
(Port=1521) 
) y 
) 
(CONNECT_DATA= (SID=ds) 
) 
) 
{ DOCNAME=deer ) 
(VERSION= 34611200) 
(RETRY = 600)) 
names .config_checkpoint_file= cfg00406 
names.trace_level= OFF 
names.trace_unique= OFF 


LAAN TT 


Defining Client Profiles 
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Client profiles are created automatically by Network Manager. For every 
community created and for every node that is a member of more than 
one community, Network Manager creates a client profile. 


Each client or set of similar clients needs to be assigned a client profile. 
The complete definition of a client profile includes an intersection of the 
position of the client in the TNS network, and its relation to the Names 
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Servers in its administrative region. The following two sets of 
information make up the client profile: 


e community—Each client is defined in terms of what community it 
belongs to, and which Interchange(s) it prefers to try, in order, 
when connecting to other communities. 


Oracle Names—Each client is also defined by the default domain 
it uses, and the list of Names Servers, in order, that should be 
contacted to resolve global names. 


Ina flat naming model, when defined by Network Manager, the default 
domain for all clients is the WORLD domain; that is, all clients and 
services reside in the WORLD domain. (Without SQLNET.ORA, the 
default domain is [ROOT] or ”.”) For example, a global database service 
name ina flat model might be SALES.WORLD. A global database 
service name in a hierarchical model might be HR.US.ORACLE.COM. 


All clients that belong to the same community, use the same 
Interchanges, and use the same Names Servers can share a single client 
profile. Any variation requires a separate client profile. 








Client profiles are automatically created for you during the network 
definition process from information entered into other property sheets. 
You may want to edit the client profile if you want to designate a Names 
Server on a particular node as a preferred Names Server. 


For more information on client profiles, see the Oracle Network Manager 
Administrator's Guide. 


Client Configuration File—SQLNET.ORA 


The following configuration parameters are listed in the client 
SQLNET.ORA file. You provide these parameters using the Network 
Manager. 


e NAMES.PREFPERED_SERVERS—A mandatory list of preferred 
Names Servers, that is, an ordered list of network addresses to 
contact when a name must be resolved. The client needs to be able 
to direct the global name request to a Names Server in the 
network. Multiple Names Servers should be listed wherever 
possible for greater reliability when the preferred Names Server is 
unavailable. 


DEFAULT_DOMAIN—The default domain simplifies access to 
any service in the client default domain. Each client has a default 
domain within which service names can be partially qualified. 
Whenever a name is requested without a ”.” (period) in it, the 
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default domain is appended to the name before it is forwarded to 
the Names Server. 


Note: The default domain is not necessarily the domain where 
the client resides—it could be a domain that the client most 
often requests network services. 


e NAMES.DIRECTORY_PATH—This indicates the name resolution 
service, such as TNSNAMES.ORA or Oracle Names, that will be 
used for client name requests. 


Configuration Parameters For Clients 
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This section describes all the configurable parameters that control how 
Oracle Names Servers and their clients operate. Each section includes 
the filename in which the parameter is valid. 


These configuration parameters are either read directly from the 
network definition database by the Names Server itself, or are read by 
the client or NAMESCTL, as appropriate. 


You typically enter and maintain most of these parameters by using the 
Oracle Network Manager, which places them in the configuration files 
that it generates. 


The configuration parameters described include those that apply to: 


e Clients that access a Names Server. The second section lists the 
parameters available to a client accessing a Names Server. 


e The Names Control Utility (NAMESCTL) 


The configuration files should not be manually edited. The exception is 
the SOLNET.ORA file because Network Manager only provides a few of 
its possible parameters (including NAMES.PREFERRED_ SERVERS, 
NAMES.DIRECTORY_PATH, and NAMES.DEFAULT_DOMAIN). All 
other parameters, including the NAMESCTL parameters, must be 
added manually using the text editor of your choice. Also, you can only 
edit configuration files that were generated by Network Manager. 


Additionally, you can use the configuration parameters on the command 
line when running the NAMESCTL utility. 
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Client Parameters 


names.default_domain 


The following client parameters, which appear in the SQLNET.ORA file 
are valid parameters for a client of Oracle Names. 





Indicates the domain from which the client most often requests names. 
When this parameter is set to the default domain name (for example, 
US.ACME), the domain name will be automatically appended to the 
service name. For example, a client with a default_domain of US.ACME 
can request a database service named FINANCE.US.ACME as: 


sqlplus scott/tiger@PINANCE 


All names outside the default domain must be fully specified as global 
names; for example, FINANCE.US.ACME. 


Status: generated by Network Manager 
Type: text string 

Source: Network Manager enterable field 
Default value: WORLD 

Valid in file: SQLNET.ORA 


names.default domain = <valid domain name> 


Note: The Network Manager automatically adds the 
NAME.DEFAULT_ZONE parameter in addition to the 
NAMES.DEFAULT_DOMAIN for backward compatibility. 
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names.preferred_servers Indicates the Names servers that will be used for a client’s name 
requests. Lists one or more Names Servers in the order they will be used 
for name requests. 


Status: mandatory 

Type: TNS address 

Source: Network Manager selection list 
Valid in file: SQLNET.ORA 


Note: The Network Manager adds the 
NAMES.PREFERRED_SERVERS parameter to the 
SQLNET.ORA file for backward compatibility with earlier 
versions of SQL*Net. 
names .preferred_servers = 
(ADDRESS_LIST = 
(ADDRESS = 
(COMMUNITY = community) 
(PROTOCOL = protocol) 
(HOST = hostname) 
{PORT = portnumber) 
) 
(ADDRESS = 
(COMMUNITY = community) 
(PROTOCOL = protocol) 
(HOST = hostname) 
(PORT = portnumber) 
) 


) 
The following example shows the NAMES.PREFERRED_SERVER 
parameter using a TCP/IP protocol: 


name.preferred_servers = 
(ADDRESS_LIST = 
(ADDRESS = 
(COMMUNITY = TCP,HOCKEY) 
(PROTOCOL = TCP) 
(HOST = messier) 
(PORT = 1600) 
) 
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names.directory_path 





Indicates the Names service, such as TNSNames or Oracle Names, that 
will be used for client name requests. 


Status: mandatory 

Type: TNS address 

Source: Network Manager selection list 
Valid in file: SQLNET.ORA 


Note: The Network Manager adds the 
NAMES.DIRECTORY_PATH parameter to the SQLNET.ORA 
file for backward compatibility with earlier versions of 
SQL*Net. 


names.directory_path = (naming_service) 


such as 
names.directory_path = (TNSNAMES, ONAMES) 
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Sample Configuration File for a Client 


Parameters for Oracle Names clients are in the SQLNET.ORA file. A 
sample of a portion of a SQLNET.ORA file is shown below. 


Note: The Network Manager automatically adds the 
NAMES.PREFERRED_SERVERS and the 
NAME.DEFAULT_ZONE parameters to the SQLNET.ORA file 
for backward compatibility with earlier versions of SQL*Net. 


TRACE_LEVEL_CLIENT = OFF 
names.default_domain = us.oracle.com 
names.directory_path = (TNSNAMES, ONAMES) 
name.default_zone = us.oracle.com 
names .preferred_servers = 
(ADDRESS_LIST = 
(ADDRESS = 
(COMMUNITY = TCPCOM.us.oracle.com) 
(PROTOCOL = TCP) 
(Host = doedoe.us.oracle.com) 
(Port = 1522) 
) 
(ADDRESS 
(COMMUNITY = TCPCOM.us.oracle.com) 
{PROTOCOL = TCP) 
(Host = one-eye.us.oracle.com) 
(Port = 42005) 


E] 


) 
) 
name.preferred_servers = 
(ADDRESS_LIST = 
(ADDRESS = 
(COMMUNITY = TCPCOM.us.oracle.com) 
(PROTOCOL = TCP) 
(Host = doedoe.us.oracle.com) 
(Port = 1522) 


E 


(ADDRESS 
(COMMUNITY = TCPCOM.us.oracle.com) 
(PROTOCOL = TCP) 

{Host = one-eye.us.oracle.com) 
(Port = 42005) 
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Names Control Utility Parameters 


namesctl.noconfirm 


namesctl.trace_level 


The valid parameters for the Oracle Names Control Utility, or 
NAMESCTL, are described below. To add any of these parameters to the 
SQLNET.ORA file, you must use a text editor. For more information on 
Names Control Utility Parameters, see Appendix A “Oracle Names 
Control Utility Reference”. 





Indicates whether sensitive changes should be prompted with a 
confirmation when running the NAMESCTL utility. 


Status: optional 

Type: Boolean 

Source: editable file entry 

Default value: OFF 

Valid values: ' OFFI ON 
SQLNET.ORA 


Valid in File: 


namesctl.noconfirm = [OFF|ON] 





Indicates the level at which the NAMESCTL program should be traced. 
Should only be used if NAMESCTL is suspected of causing problems. 


Status: optional 

Type: text string 

Source: i i editable file entry 
„Default value: "OFF ‘ 

Valid values: OFF | user | admin 

Valid in File: SQLNET.ORA 


namesctl.trace_level = [OFF|USER|ADMIN] 
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namesctl.trace_file 


namesctl.trace_directory 


namesctl.trace unique 





Indicates the file in which the NAMESCTL trace output is placed. 


Status: optional 

Type: text string 

Source: editable file entry 

Default value: namesctl_PID.trc (os ~specific) 
Valid values: valid file name (OS specific) 
Valid in File: SQLNET.ORA 


namesctl.trace_file = file_name 





Indicates the directory where trace output from the NAMESCTL utility 
is placed. 


Status: optional 

Type: text string 

Source: editable file entry 

Default value: none 

Valid values: valid directory name (OS specific) 
Valid in File: SQLNET.ORA 


namesctl.trace directory = /your_directory 





Indicates whether a process identifier is appended to the name of each 
trace file generated, so that several can coexist. By default, the value is 
OFF, which means that when a new trace file is created for the Names 
Control Utility, it overwrites the existing file. 


Status: optional 

Type: text string 
Source: editable file entry 
Default value: OFF 

Valid values: OFF | ON 

Valid in File: SQLNET.ORA 


namesctl.trace_unique = [OFF|ON] 
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namesctl.server_password Indicates the value that matches configured password in the Names 


Server. This eliminates the need to type the password each time when 
using the NAMESCTL utility. Note that it should not be used in a 
shared SQLNET.ORA file because all users would have access to it. Be 
sure that operating system privileges restrict who can read 
SQLNET.ORA when using this parameter. 


Status: optional 

Type: text string 
Source: editable file entry 
Default value: PUBLIC 

Valid values: valid password. 
Valid in File: SQLNET.ORA 


namesctl.server_password = your_password 


Defining Global Database Links 


A global database link is a link that connects each database in a network 
to all other databases. This link is created automatically by the Network 
Manager for use with Oracle Names. Each global database link created 
by Network Manager connects you to every other database server in the 
network. 


Defining Database Links 


When a database service is defined in the Network Manager, a global 
database link to each database server is automatically created from 
every other database server in the network. These global database links 
do not reside in the database’s data dictionary, but in the network 
definition from which the Names Servers loads information. The 
default global database links created when you define a database service 
do not include a CONNECT TO clause. This means that users access the 
linked database using the same usernames and passwords as they used 
to reach the first database. 

For information on configuring global database links in Network 
Manager, refer to the Oracle Network Manager Administrator's Guide. For 
more information on configuring and using public and private database 
links, see Understanding SQL*Net. Also refer to the Oracle7 Server 
Administrator's Guide. 
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Specifying Global Links with Username and Password 





You can edit global database links to include CONNECT TO data using 
Network Manager. When you edit.a database definition, you can 
specify a single default username and password for the database link. 
See the Oracle Network Manager Administrator's Guide for details on how 
to edit database links. 


Note: You can define multiple database links by using 
connection qualifiers in Network Manager; however, connection 
qualifiers for public and private database links must be defined 
locally for each database. 


Using Connection Qualifiers to Define Multiple Database Links 


Connection qualifiers to a database link (delimited by the second @ sign) 
provide a means to create multiple links to a database. Multiple 
database links to the same database provide different access routes with 
different accounts and privileges. Database link connection qualifiers are 
used with private, public, and global database links. However, in 
Network Manager, you can configure connection qualifiers with global 
database links only. 


Note: The connection qualifier username and password 
configured in Network Manager must match a valid username 
and password in the target database. 


The following examples select data from the same database 
(HR.US.ORACLE.COM), but use three distinct database links. Each 
database link accesses different accounts on the same database with a 
different set of access privileges. 


SELECT * FROM emp@hr.us.oracle,.com; 
SELECT * FROM schedule@hr.us.oracle.com@admin; 
SELECT * FROM emp_salaries@hr.us.oracle.com@fin; 


In the above example, @admin and @fin are connection qualifiers. Each 
of the above links could be resolved as a private, public, or Oracle 
Names (global) database link. 


USING Clause No Longer Necessary in Public and Private Links 
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Unless you want to include a username/ password or override the 
CONNECT TO clause, you do not need to create public or private 
database links for each local database. In fact, because Oracle Names 
stores names and addresses, the database string (specified by the USING 
‘dbstring’ clause in the CREATE DATABASE LINK command) is no 
longer necessary, providing that dbstring is a database name defined in 
the Names Server. 


Oracle Names Administrator's Guide 


| 
| 
ji 
| 





Restrictions on Global Database Names 


When GLOBAL_NAMES = TRUE in a database initialization file, the 
global database name used in the database link must match the 
GLOBAL_NAME parameter name of the database it connects to. This 
helps to ensure that each database link connects to the correct database. 


It is recommended that global database names be assigned either when 
databases are created or when Oracle Names is installed. Thereafter it is 
recommended that you not change global database names unless 
absolutely necessary. 


SQL*Net requires that all global names be fewer than or equal to 64 
characters in length. 


Using Aliases For Database Links 


Aliases are typically used if a database service or database link must be 
referred to by more than one name. Aliases can save the administrator 
from maintaining multiple copies of data just to provide the same 
service under two names. 


Additionally, a network administrator could create aliases so that users 
can connect to a database or use a database link by using a simple name 
instead of having to specify the global database name or global database 
link name (that is, the fully~qualified name). Refer to the Oracle Network 
Manager Administrator's Guide for information on how to configure 
service name aliases. 
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CHAPTER 


Running and Managing 
Oracle Names 


T his chapter describes operations you need to perform to maintain 
individual Names Servers and the Oracle Names system. 


These operations assume that you have successfully installed and 
configured the Names Servers as described in the previous chapters. 


Note: Information on configuring and distributing 
configuration files, and performing initial testing is documented 
in the Oracle Network Manager Administrator's Guide. 
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Basic NAMESCTL Operations 


Starting a Server 


Shutting Down a Server 


This section describes a handful of common management tasks for the 
Names Servers, and the commands you can perform with the Names 
Control Utility program. By using this tool, you can execute such 
commands as STARTUP, SHUTDOWN, and so on. Additionally, you 
can view and change Names Server parameter settings, and perform 
other operations for Oracle Names: ` 


See Appendix A, “Oracle Names Control Utility Reference,” for more 
information on the Names Control Utility program. 


The STARTUP command loads the Names Server into memory and tells 
it to begin executing. At startup, the Names Server loads its 
configuration, loads its data, then becomes available to answer requests. 


NAMESCTL> STARTUP 


The SHUTDOWN command stops the execution of a Names Server. The 
program stops executing, and releases any machine resources being 
used, 


NAMESCTL> SHUTDOWN 


Handling Data Change Requests on a Names Server 


A method for requesting to add, change, or delete network objects and 
their associated names from the Names Server is required. When a DBA 
installs a new database server or configures a database link, a form 
similar to the “Oracle Names Request Form” should be filed, either 
through an e-mail message, a phone message, a paper form, or other 
convenient method. The administrator can then modify the data and 
refresh the Names Servers at regular intervals. 


The simplest method of organizing service requests in your organization 
is an electronic mail account either explicitly used for Oracle Names, or 
shared for general system requests. The benefit of a dedicated Oracle 
Names e-mail account is that messages are immediately received by the 
Names administrator. With a general electronic mail account, they are 
usually fielded by a dispatcher and forwarded to the Names 
administrator. 
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Reloading Data 


The following illustration shows a sample for the contents of an Oracle 
Names request form or e-mail template. 





ACME Oracle Names Request Form 


Use this form to request additions or changes to databases or 
database links defined in the Oracle Names system. All fields 
must be filled in. 


Which of the following is being requested? 


Add a new name 
Change an existing name 
Delete an existing name 


Object type requested: 

_.. database service (as in sqlplus scott/ tiger@object-name) 
— database link (as in select * from emp@object_name) 

__ alias (alternative name for one of the above) 


Name Requested: 


























Requested by: Ext: 
Object Owner: Ext: 
Required by: 
Resson for Nane 
Ge | 
If a database (Supply at least one address): 
COMMUNITY. COMMUNITY. 
ADDRESS ADDRESS 
SID 
A | 
N If an alias: 
If a database link: Alias: 
DB Account: 
Password: 
Database: 














Figure 7-1 Oracle Names Request Form 


When any data from an administrative region changes, you must reload 
the Names Servers in that region for the changes to be read. This 
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includes changes to the set of Names Servers in that region, or database 

names and database links that have been added, deleted, or changed by 
using the Network Manager. Reloading flushes all local data, then loads 
a new copy from the network definition. 


You can also reload data by using Reload Names Servers from the 
Control menu in the Network Manager. All Names Servers in the region 
will be reloaded one at a time. 


In distributed administration installations, any non-authoritative data 
stored in Names Servers is unaffected. To remove non-authoritative 
data from a Names Server’s cache use the FLUSH command, or use the 
RESTART command instead of RELOAD. (RESTART preserves “live” 
cache; that is, foreign data whose TTL has not yet expired.) 


Note: For more information about authoritative data and 
non-authoritative data, see Appendix C, “Advanced Topics”. 


Each Names Server also regularly checks to see if any data has changed 
since the last reload. This ensures that all changes are seen, even if the 
administrator forgets to reload. By default, the interval between checks 
is 10 minutes. 


Testing Names Server Availability 


To test that a Names Server is operating correctly, use the PING 
command. Following are ways to ping the Names Server LABRADOR 
in the US.ACME domain. 


NAMESCTL> PING LABRADOR.US.ACME 


You can also PING multiple Names Servers by using a single command, 
for example: 


NAMESC'TL>PING HUEY.UK.ACME DUEY.UK.ACME LOUIE.UK.ACME 


The PING command responds with the time it takes to contact the 
server and return an acknowledgment. 


If PING fails, make sure the server has been started. If it has been, 
double-check the configuration in the Network Manager, especially the 
defined address of the Names Server in question. 


Maintaining Names Servers 


All installations have the problem of physically maintaining computers. 
Many, but not all, activities can be performed remotely by the 
administrator. 
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Names Servers may be installed outside of central data center locations 
for greater availability to outlying clients. Wherever Names Servers are 
installed, one or more individuals need to be responsible for assisting in 
keeping them up and running. 


Conditions Causing Oracle Names Failures 


Failure is identified either by a timeout at the client when waiting for a 
response from the Names Server, or by the inability to contact the 
Names Server at all. 


When an Oracle Names Server cannot be reached, the client will contact 
the next Names Server in its preferred Names Server list. The failure of a 
specific Names Server does not affect the operation of any other Names 
Server in that administrative region or any other region. 


Testing Network Objects 


Removing Foreign Data 


To test that a network object exists, use the QUERY:command. The 
syntax for this command is as follows: 


NAMESCTL> QUERY global_object_name type 


Database service names have the type A.SMD, and database links have 
the type DL.RDBMS.OMD. The following example shows a query of the 
database service name BUGSY in the MACS.ACME domain: 


NAMESCTL> QUERY BUGSY.MACS.ACME A.SMD 


The QUERY command returns the amount of time the transaction took 
and information about the network object. 


Ina distributed installation, you can remove all non-authoritative data 
from a server cache by using the FLUSH command: 


NAMESCTL> FLUSH 


As shown, this command flushes the current Names Server. If you want 
to flush another Names Server or multiple Names Servers, supply their 
names as arguments to the FLUSH command. Refer to Appendix A, 
“Oracle Names Control Utility Reference”, for more information. 


You would typically use this command only if the Names Server seems 
to be providing inaccurate responses. Removing non-authoritative data 
removes any data that may be incorrect. The cost is that all 
non-authoritative data must be looked up again. 
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Removing Data for Individual Network Objects 


DRS SN a race] 


Testing from a Client 


Client Configuration 


Once you have determined that an individual foreign object is out of 
date or inaccurate, you can flush data for this object only by using the 
command: 


NAMESCTL> FLUSH_NAME FINANCE.UK.ACME 


You can flush only one name ata time, and only from the current Names 
Server. 


When the Names control commands such as PING and QUERY appear 
to be working, you should test a number of SQL*Net initiated 
connections that are resolved by the Names Server. 


The client requires a SQLNET.ORA file with one or more Names Server 
addresses defined in the NAMES.PREFERRED_SERVERS parameter. 
These Names Servers are contacted in order until a response is returned. 
Additionally, each client default domain is set with the 
NAMES.DEFAULT_DOMAIN parameter to simplify how domains are 
specified during connection requests and when using NAMESCTL. 


Both parameters, as well as the rest of the SQLNET.ORA file, are 
generated by the Network Manager as part of the client profiles. 


How Clients Request Network Objects 


To request access to a network object, the client uses the familiar 
client/server connection syntax: 


sqlplus scott/tiger@FINANCE 
For details on connecting from a specific tool, see the manual for that 


tool. For general notes on initiating SQL*Net connections, see 
Understanding SQL*Net. 
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Testing Distributed Database Links 


Server Configuration 


If you will be using Oracle Names in distributed databases, you should 
also test that database links are being properly resolved. 


The Names Server that'will coordinate the transaction must also be able 
to function as a client, as described in the previous section. This means 
that the SQLNET.ORA file must contain a defined 
NAMES.PREFERRED_SERVERS parameter. You define this parameter 
in Network Manager, and Network Manager then generates this 
parameter as part of the SQLNET.ORA file for the client profiles. 


Using Database Links with Oracle Names 


Database Link Security 


When a server initiates the use of a database link, the Names Server is 
called, and the request is executed, as with locally defined database 
links (links defined in the local database data dictionary). Consider, for 
example, the SQL statement shown: 


SELECT A.ITEM, B.COST 
FROM PARTS A, PRICE@FINANCE.US.ACME B 
WHERE A.PARTNO = B.PARTNO; 


FINANCE.US.ACME is looked up in the Names Server. Then the link is 
established between the current database and the FINANCE database. 
(FINANCE is the name of the database service, as well as the name of 
the global-database link.) 


For more information on how to define global database links, refer to 
the following documents: 


o Oracle Network Manager Administrator's Guide 
e Understanding SQL*Net 
e Oracle7 Server Administrator’s Guide 


e Oracle7 Server Concepts 


Any database link stored in the Names Server with an explicit username 
and password should contain only data that is regarded as public. 
Storing such a name allows any user through any server to view the 
data in that account. 
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You can provide security by creating database links that omit the 
username and password. If you do not enter a username and password, 
whoever uses the database link will use their own username and 
password to make the connection. This requires that multiple user 
accounts in multiple systems have the same usernames and passwords. 
All users can request the use of the database link, but only users with 
valid accounts and access to the tables at the remote Names Server will 
be able to see the data. 


Database Link Search Path 


When a database link is used to select information from a remote 
database table (for example, SELECT * FROM 
EMP@HR.US.ORACLE.COM), Oracle searches for a connect descriptor 
in the following locations in the following order: 


1. the user’s private database links 
2. the database public database links 
3. the Oracle Names Server global database links 


Oracle ends the search when a USING clause is found in either a private 
or public database link. If a USING clause is not found in a private or 
public link, then the global database link is used. If a connect descriptor 
is not found, the following message is returned: 


ORA-02019: “connection description for remote database not found” 


If a CONNECT TO clause (username/ password) is found in any of the 
searched database links, the first one found is used. If none are found, 
then the current username and password will be used. 


CA 


Diagnosing Names Server Failures 


Names Not Retrieved 


There is a small number of common problems when starting and using a 
Names Server as summarized in this section. 


If a Names Server fails to return a name, try one or more of the 
following: 


In all networks (central and distributed): 


+ Check the setting for the default domain using SHOW 
DEFAULT_DOMAIN. Remember that the default domain is 
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appended to all unqualified names (names without a ”.”). To be 
sure that the default domain is not at fault, query the fully 
qualified name by using the command: 


NAMESCTL>QUERY full_name type 


The most common object type is a network address which is usually 
ASMD. 


+ Execute the STATUS command on the configured Names Server 
for the client. The client's default Names Server is the first one in 


the NAMES.PREFERRED_SERVERS parameter in SQLNET.ORA. 


Note: You can run these commands from any machine; you do 
not have to run them from the client or Names Server machine. 


You can point to the Names Server in question from any 
NAMESCTL program by using the command: 


NAMESCTL>SET SERVER names_server 
You may also want to try: 


NAMESCTL>PING names_server 


In a distributed administration network: 


¢ Check to see if the Names Server responded with an authoritative 
or non-authoritative answer. To do so, use the following 
command against the responding Names Server: 


NAMESCTL>QUERY name type 


If the response includes the line “Authoritative Answer : 
No” the cached data may be out of date. Make a note of the 
answer. 


~ If the answer is non-authoritative, load the authoritative 
answer by using: 


NAMESCTL>QUERY name type AUTHORITY 


This forces the name to be looked up at its authoritative 
source. Notice that the line “Authoritative Answer: Yes” is 
included in the response. 


~ Compare the old value to the results of the second query. If 
the details are different, then the data did change. Be aware 
that other Names Servers may also have an old version of 
this name. 
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Names Server Not Found 


e If a name you know should exist is not being retrieved, try other 
names in the same domain, or the same administrative region. Try 
to identify whether the failure is on the individual name, or 
whether all names in the region are not being retrieved. 


— Use the TRACE modifier on a QUERY to have the Names 
Server search path returned: 


NAMESCTL>QUERY name type TRACE 


— See if a Names Server serving the desired administrative 
region is accessed. 


Because the default Names Server is always in the client’s community 
and administrative region, the failure is usually due to a configuration 
error, or because the network or the Names Server is unavailable. 


e Check that the client has a valid SQLNET.ORA file in the correct 
location. Note that there is a user’s SQLNET.ORA file and a 
system-level SQLNET.ORA file. Examples of these filenames and 
locations are ~/SQLNET.ORA and 
$TNS_ADMIN/SQLNET.ORA. Where both exist, the local file is 
used. These filenames and locations are operating-system specific. 
See the Oracle manuals for your operating system for the 
appropriate location. 





Check that the preferred Names Server is available using the 
STATUS command: 


STATUS names_server 


Check that the address in the NAMES.PREFERRED_SERVERS 
parameter is the same as the one defined in Network Manager. 
The client file may be out of date. 


If you receive the error: 


NNL-00018: Warning: could not contact default name server 


when loading NAMESCTL, it usually means that the configured Names 
Server is not available (that is, not started), or that it is incorrectly 
configured. 
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Parameter File Not Found 


When starting either the Names Server or the NAMESCTL utility, each 
expects to find a parameter file with the startup details. If the file does 
not exist, a message will be returned indicating what file is expected. 


For example, on UNIX if you attempt to start a Names Server when no 
NAMES.ORA file exists, you receive the following error message: 


NL-00462 error loading parameter file 
/oracle/network/admin/names.ora 
SNL-00821 File does not exist. 


i 
i 
i 
i 
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APPENDIX 








Oracle Names Control 
Utility Reference 


T his chapter is a complete reference for the Oracle Names Control 
Utility (also known as NAMESCTL). This appendix is intended to be 
used as a reference. Each command includes notes on how to use the 
command individually. 


You can use the Oracle Names Control Utility to perform basic 
management functions on one or more Names Servers. By using this 
tool, you can execute such commands as STARTUP, SHUTDOWN, and 
STATUS. Additionally, you can view and change Names Server 
parameter settings such as RESET_STATS_INTERVAL and 
TRACE_LEVEL. 
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Using NAMESCTL 


NAMBESCTL is a basic utility for controlling Oracle Names Servers. It 
contains several types of commands: 


Operational commands such as STARTUP, SHUTDOWN, 
RESTART, and so forth. 


Modifier commands, such as SET property. 


Informational commands, such as STATUS, SHOW property, and 
PING. 


Command utility operational commands such as EXIT, QUIT, and 
HELP. 


NAMESCTL Operating Modes 
You can run NAMESCTL in three modes: 
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Interpreter mode - NAMESCTL is loaded and all operations are 
executed within it. When loaded, the program displays the 
following prompt: 


NAMESCTL> 


Command line mode - You can also execute most commands from 
the operating system command line by running the NAMESCTL 
program with a complete command as a parameter to the 
program. In this case, NAMESCTL will load and execute the 
command, then return the operating system prompt. Sample 
commands are: 


NAMESCTL START 
NAMESCTL STATUS CHEDDAR .ACME 


Batch command mode - You can combine commands in a 
standard text file, then run them as a sequence of commands. To 
execute in batch mode, use the format: 


NAMESCTL @file_name 


You can use either REM or # to identify comments in the batch 
script; all other lines are considered commands. Any commands 
that would typically require confirmation do not require 
confirmation during batch execution. 
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Using Parameter Options 


When loading NAMESCTL, any valid parameter settings can be passed 
to the program to override the default or configured settings. For 
example: 


NAMESCTL NAMESCTL.TRACE_LEVEL=ADMIN 
would load NAMESCTL and turn on tracing to the ADMIN level, 


regardless of the currently configured value of 
NAMESCTL.TRACE_LEVEL. 


Using the SET and SHOW Modifiers 


You can use the modifier SET to change the properties of the Names 
Server or the Names Control Utility environment. When a property is 
set, it changes the value of a Names Server parameter, often causing 
immediate results, and also affecting all commands that follow. For 
example, the following sequence will set a server to control and change 
its trace level. 


NAMESCTL> SET SERVER DOLPHIN.WORLD 
NAMESCTL> SET TRACE_LEVEL ADMIN 


The first modifier sets the server on which subsequent commands will 
perform. The second modifier sets the server DOLPHIN.WORLD’s trace 
level. All operations that you perform after the second command will be 
traced at the ADMIN level. 


NAMESCTL’s Distributed Operation 


The NAMESCTL program can operate on a Names Server on the same 
machine or any other Names Servers in the network. Some of the 
commands are limited to the local machine, but most can be executed 
across the network. This is very useful when a single administrator is 
managing all of the Names Servers in a region, or wants to check the 
availability of a specific Names Server. 


Most commands will accept the name of a Names Server as the last 
argument indicating which Names Server to perform the command 
against. If omitted, the current Names Server is used. For example: 


SHOW SYSTEM_QUERIES DOLPHIN, ACME 


will display the system queries on the Names Server DOLPHIN.ACME 
and when they will next occur. 


Oracle Names Control Utility Reference A-3 





NAMESCTL Security 


To perform a series of commands against an individual Names Server, 
type 
NAMESCTL> SET SERVER server name 


then perform the commands. 


You MUST perform the STARTUP command on the Names Server 
machine itself, not from a remote location in the network. After a Names 
Server has started, you can then perform all other operations, including 
RESTART, remotely, subject to the security restrictions below. 


You have the option of configuring a Names Server to require a 
password for any NAMESCTL command that alters how it operates. 


If you do not enter anything in the Password field on the Names Server 

property sheet in the Oracle Network Manager, no password is required 
to control any Names Server function. This would be common for a test 

Names Server, or an evaluation of the Names product. 


If you do supply a password on the Names Server property sheet in the 
Network Manager, you must also set the password property in the 
NAMESCTL program. If this is not done, the Names Server will not 
respond to some NAMESCTL commands. 


Initially, the value for PASSWORD is set to the value specified for the 
NAMESCTL.SERVER,. PASSWORD parameter in the SQLNET.ORA file 
on the node running NAMESCTL. This would commonly be the 
password of the first Names Server listed in the PREFERRED_SERVERS 
list. The current setting for PASSWORD must match the value entered 
through the Network Manager, or the value in the NAMES.PASSWORD 
parameter in the NAMES.ORA file on the current Names Server. 


If you are concerned with the security implications of explicitly putting 
a Names Server password in the administrator’s client SQLNET.ORA 
file, you can omit the parameter and always use the command: 


SET PASSWORD 
You will be prompted for the password. When passed over the 


network, the password is ALWAYS encrypted, regardless of how it is set 
in NAMESCTL. 
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Confirmation Mode in NAMESCTL 


Some of the NAMESCTL commands require your confirmation before 
they are executed. When you issue the command, you are prompted: 


confirm: [yes or no] 


Type “yes” to execute the command; type “no” to cancel the command. 


You can turn confirmation modeoff by using by setting the parameter 


NAMESCTL .NOCONFIRM 


TRUE 


in the SQLNET.ORA file. Note that with this parameter set to OFF, all 
commands execute without asking for confirmation. 


Summary of NAMESCTL Commands 


EXIT 
FLUSH 
FLUSH_NAME 


HELP 
LOG_STATS 
PING 
QUERY 


QUIT 
REGISTER 


RELOAD 
REPEAT 
RESET_STATS 


RESTART 


SET DEFAULT_DOMAIN 


Exit the NAMESCTL utility. 
Flush all foreign names from the cache. 


Flush an individual name from the foreign 
data cache. 


Get brief general or specific help on 
commands, 


Log the current statistics to the log file. 


Test for the existence of a Names Server, 
and get the time it took for the Names 
Server to respond. 


Query for the existence or contents of a 
network object name. 


Quit the NAMESCTL utility. 


Registers a network object to a Names 
Server 


Reload the local region data into the cache. 


Perform a query repeatedly for n iterations. 


Reset the current Names Server’s statistics 
to the same state as STARTUP. 


Restart the Names Server. 


Set or change the default domain for the 
NAMESCTL client. 
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SET FORWARDING. 
AVAILABLE 


SET 
LOG_STATS_INTERVAL 


SET 
NAMESCTL_TRACE 
_LEVEL 


SET PASSWORD 


SET 
REQUESTS_ENABLED 


SET RESET_STATS_ 
INTERVAL 


SET SERVER 

SET TRACE _LEVEL 
SHOW 

CACHE, CHECKPOINT_ 
INTERVAL 


SHOW FORWARDING_ 
AVAILABLE 


SHOW 
DEFAULT_DOMAIN 


SHOW LOG_FILE_NAME 


SHOW 
LOG_STATS_INTERVAL 


SHOW 
NAMESCTL_TRACE 
_LEVEL 


SHOW 
REQUESTS_ENABLED 
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Turn on or off name request forwarding for 
a Names Server. 


Changes the frequency with which statistics 
are logged to the log file. 


Sets level at which NAMESCTL can be 
traced. 


Registers password for privileged Names 
Server operations such as RELOAD and 
STOP. 


Determine whether the current Names 
Server will respond to requests. 


Change time between statistics being reset 
to zero or initial values in current Names 
Server. 


Change the current Names Server. 


Changes the trace level for tracing the 
current Names Server. 


Shows the frequency with which the Names 
Server cache is written to the checkpoint 
file. 


Shows whether Names Server is 
forwarding requests or redirecting them. 


Display default domain of current Names 
Server. 


Shows the name of the file which the 
Names Server writes the logging 
information. 


Displays the frequency with which statistics 
are logged to the logfile. 


Display the current trace level of the 
NAMESCTL program. 


Shows whether or not the Names Server is 
responding to requests. 


SHOW RESET_STATS_ 
INTERVAL 


SHOW SERVER 


” SHOW STATUS 


SHOW 
SYSTEM_QUERIES 


SHOW TRACE_FILE_ 
NAME 


SHOW TRACE_LEVEL 
SHOW VERSION 


SHUTDOWN or STOP 
START or STARTUP 
STATUS 


STOP 
TIMED_QUERY 


UNREGISTER 


VERSION 


Displays the frequency with which internal 
statistics are reset 


Displays name and version of current 
Names Server. 


Displays general status information about 
he Names Server. 


Displays information about system queries 
rom the Names Server. 


Shows the name of the file where the 
Names Server writes the trace information. 


Display trace level of current Names Server. 





Displays the version banner for the Names 
Server 


Stop the Names Server. 
Start the Names Server. 


Display the status of the current Names 
Server. 


Stops one or more Names Servers. 


Show all registered data in the Names 
Server cache. 


Removes a network object from a Names 
Server 


Displays the version banner for the Names 
Server. 
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EXIT 


Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


The EXIT command closes the NAMESCTL program. 
The NAMESCTL program must be loaded. 
No. 


From NAMESCTL program: 
EXIT 


None. 


EXIT has no effect on any Names Servers. It affects only the NAMESCTL 
program. 


The EXIT command is the same as the QUIT command. 


NAMESCTL> EXIT 
NAMESCTL finished. 
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FLUSH 





Purpose: 


Prerequisites: 


Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Drop all stored non-authoritative data from the Names Server cache. 


Only relevant with distributed administration, (In central 
administration there is no non-authoritative data.) 


Yes. 


From the operating system prompt: 


NAMESCTL FLUSH [server] 


From NAMESCTL program: 
FLUSH [server] 


Zero or more Server names separated by a space. When no arguments 
are supplied, only the current Names Server's cache is flushed of foreign 
names. 


FLUSH erases all foreign data that has been cached. Typically, you should 
flush the foreign data cache when: 


e A large volume of data changes in the network and the normal 
TTL aging mechanism will take too long. 


e When unidentifiable errors in name resolution of cached foreign 
data are occurring. Flushing all foreign data from the cache forces 
it to be looked up again when it is requested the next time. 


au i 


NAMESCTL>FLUSH 
Confirm [yes or no]: yes 
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FLUSH_NAME 


Purpose: 


Prerequisites: 


Password Required: 
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Syntax: 


Arguments: 


Usage Notes: 


Example: 


Drop one or more specific non—authoritative names from the current 
Names Server’s cache. 


Only meaningful with distributed administration. (In central 
administration, there is no non-authoritative data.) 


Yes. 


From the operating system prompt: 
NAMESCTL FLUSH_NAME name 


From NAMESCTL program: 
FLUSH_NAME name 


A single name. 


FLUSH_NAME erases only data cached from outside the Names 
Server’s region (that is, non-authoritative data). It is typically flushed 
when a name is behaving unusually, suggesting the source copy may 
have changed. 


FLUSH_NAME removes the name from the current foreign data cache 
as well as any other Servers between the current region and the 
authoritative region. (In other words, any non-authoritative names that 
have been cached along the original lookup route are flushed.) 


Names are flushed from the current Names Server. The current Names 
Server is either the default preferred Names Server or the one set by 
using the SET SERVER command. 


NAMESCTL>FLUSH_NAME MOUNTAIN. ACME .COM 
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HELP 





Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Provides details of the NAMESCTL commands. 


None. 
No. 


From the operating system prompt: 
NAMESCTL HELP [command] 
From NAMESCTL program: 


HELP [command] 


commands 


Help provides brief reminders of the function of each command in 
NAMESCTL. 


When no arguments are supplied, help shows the list of valid 
commands, 


When you supply an argument, a one line description of that 
command's function is displayed. 


NAMESCTL> HELP 

The following operations are available 

An asterisk (*) denotes a modifier or extended 
command: 


exit flush flush_name log stats 
ping query quit reload 
repeat* reset stats restart set* 
show* shutdown start startup 
status stop version 


NAMESCTL> HELP PING 
Sends an echo request and displays the round trip 
time. 
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LOG_STATS 


Password Required: 


A-12 


Purpose: 


Prerequisites: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Logs the current. set of Names Server statistics to the configured log file 
for that Names Server. 


None. 

Yes. 

From the operating system prompt: 
NAMESCTL LOG_STATS [server] 


From NAMESCTL program: 


LOG_STATS [server] 


Zero or more Names Server names separated by a space. When no 
arguments are supplied, only the statistics for the current Names Server 
are reset. 


Statistics may be logged if the STATUS command or other behavior 
indicates some data that you would like to capture in the log. 
LOG_STATS does not affect the current LOG_STATS_INTERVAL. 


NAMESCTL>LOG_STATS 
Statistics counters logged. 
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PING 





Purpose: 


Prerequisites: 


Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Contact the current Names Server, or named server(s), and display the 


request/response time. 
None. 
No. 


From the operating system prompt: 
NAMESCTL PING [server_name] 
From NAMESCTL program: 


PING [server_name] 


Zero or more Names Server names separated by a space. When no 
arguments are supplied, only the current Names Server is pinged. 


Ping serves two basic purposes: 


e Jt ensures that a Names Server is functioning. 


e It shows typical response times from the location of the 
NAMESCTL user to a Names Server. 


NAMESCTL> ping NSERVER.world 
Round trip time is 0.04: seconds 
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QUERY 





Purpose: 


Prerequisites: 
Password Required: 


Syntax: 


Test or retrieve the contents of a network object stored in the Names 
Server. 


None. 
No. 


From the operating system prompt: 

NAMESCTL QUERY object_name [object_type} [modifiers] 
From NAMESCTL program: 

QUERY name [type] [modifiers] 


Valid types: 

ASMD Network addresses, as with database 
service definitions. 

CNAME.SMD Alias name (sometimes referred to as 
“canonical name”), 

DL.RDBMS.OMD Database link. 

NS.SMD Names Server addresses. System data used 
to communicate between Names Servers. 

VIADD.NPO.OMD SQL*Net Version 1 connect string 

Valid Modifiers: 

AUTHORITY Forces the query to be resolved at the 


source of the data (in the administrative 
region where the data is considered local) 
even if the data is in the local cache. This 
could be used if the administrator suspects 
that the data has changed at the source. 


NOFORWARD Query for the data, but don’t forward the 
request. When the data is not local, and 
noforward is specified, the query will not 
be resolved. 


TRACE Allows a trace of the path to the answer. 
This is useful whenever you want to find 
out which Names Servers the request went 
to. 
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Arguments: 


Usage Notes: 


Example: 


Mandatory network object name and network object type. 


QUERY can be used to test that a defined piece of data can be found, 
and that the contents are correct. 


The QUERY command always operates on the current Names Server, 
either the default, or as specified using the SET SERVER command. 


If the QUERY command is used with just a name as a parameter, the 
Names Server responds with the number of pieces of data with that 
name, and the time required to complete the operation. 


If the QUERY command is used with the name and type supplied as 
arguments; the specific name is looked up and returned to the user. 





The QUERY command can take multiple arguments if appropriate. For 
example: 


QUERY NAME.WORLD A.SMD AUTHORITY TRACE 


NAMESCTL> QUERY BONES.DEM.MEDICINE A.SMD 


Total response time: 0.04 seconds 
Response status: normal, successful completion 
Authoritative answer: yes 
Number of answers: a 
Canonical name: bones .dem.medicine 
TTL: 1 day 
Alias translations: 
from: bones .dem.medicine 
to: bones ,dem.medicine 
Answers: 


data type is “a,smd” 
Syntax is ADDR:...(DESCRIPTION= (ADDRESS= 
(COMMUNITY=tep) (PROTOCOL=TCP) (Host=cowboy) 
(Port=1522)) (CONNECT _DATA=(SID=rodeo) ) ) 
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QUIT 


Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 





The QUIT command quits the NAMESCTL program. 
The NAMESCTL program must be loaded. 

No. 

From NAMESCTL program: 

QUIT 

None. 


QUIT has no effect on any Names Servers. It affects only the 
NAMESCTL program. 


The QUIT command is functionally equivalent to the EXIT command. 


NAMESCTL> QUIT 
NL-00851: NAMESCTL Finished 
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REGISTER (Dynamic Discovery Option Only) 








Purpose: 


Prerequisites: 


Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


To register a network object to a Names Server 


None. 


From the operating system prompt: 


namesctl register object_name [-t type_of_service] 
[-d data] [-h hostname] 


Or, from the NAMESCTL program: 


register object_name [-t type_of_service] [-d data] 


Mandatory object name. The service and data are not necessary to make 
the registration process appear to work: However, they are necessary to 
make the registration useful. In other words, an object name registered 
without an address cannot be used. 


Provides a manual mechanism for registering a service, its type, and its 
address. Both the type of service and the data may be any valid string, 
but the typical registration has either “database” or “listener” as type of 
service, and the TNS address as the data. 


The object registration is propagated to all other well known Names 
Servers in the region by the current well known Names Server. 


NAMESCTL> register parts -t database -d (DESCRIPTION= 
(ADDRESS= (PROTOCOL=TCP) (HOST=nineva) 
(PORT=1387) ) (CONNECT_DATA= (SID=db3) ) ) 
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RELOAD 


Password Required: 
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Purpose: 


Prerequisites: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 





Forces the server to check immediately for data changes in its 
administrative region, and if there are any, reloads all database service 
names, global database links, and aliases. 


None. 
Yes. 


From the operating system prompt: 
NAMESCTL RELOAD [servers] 


From NAMESCTL program: 


RELOAD [servers] 


Zero or more Names Server names separated by a space. When no 
arguments are supplied, only the current Names Server is reloaded. 


All Names Servers load their data directly from the Network Manager’s 
network definition database. You do not need to distribute any 
configuration files. 


In distributed administration, RELOAD affects only the data for the 
current administrative region. All foreign data in the cache is 
unchanged. 


NAMESCTL>RELOAD 
Server reloaded. 
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REPEAT 


Purpose: 


Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Used to perform QUERY multiple times to compute average return 
rates. 


None. 
No. 


From the operating system prompt: 
NAMESCTL REPEAT number QUERY <type> 


From NAMESCTL program: 
REPEAT number QUERY type 


where number is an integer and type is as shown in the QUERY 
command, 


None. 


Repeat is useful for understanding the average response time over a 
number of requests. 


Do not specify too large a number here; while the number of iterations 
are occurring, the NAMESCTL program cannot do anything else. 


NAMESCTL> repeat 10 query manatee a.smd 
Number of requests: 10 

Average response time: 0.01 seconds 
Minimum response time: 0.01 seconds 
Maximum response time: 0.04 seconds 


Total response time: 0.14 seconds 

Response status: normal, successful completion 
Authoritative answer: yes 

Number of answers: aE 

TTL: 1 day 

Answers: 


data type is “a.smd” 
Syntax is ADDR: (DESCRIPTION= (ADDRESS= 


(COMMUNITY=tcp) (PROTOCOL=TCP) (Host=salmon) 
(Port=1522) ) (CONNECT_DATA=(SID=otter) }) 
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RESET_STATS 





Purpose: 


Prerequisites: 


Password Required: 
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Syntax: 


Arguments: 


Usage Notes: 


Example: 


Reset the Names Server statistics to the original values of the Names 
Server at startup. 


None. 
Yes. 


From the operating system prompt: 


NAMESCTL RESET_STATS [server] 


From NAMESCTL program: 
RESET_STATS [server] 


Zero or more Names Server names separated by a space. When no 
arguments are supplied, only the current Names Server's statistics are 
reset. 


RESET_STATS has the same effect as waiting for the 
RESET_STATS_INTERVAL to conclude, except that it happens 
immediately. 


NAMESCTL> RESET_STATS 
Confirm [yes or no]: yes 
Server statistics reset. 
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RESTART 
a ee a 


Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Initiate a reset of a Names Server to its original state at startup. 
None. 
Yes. 


From the operating system prompt: 
NAMESCTL RESTART [server] 


From NAMESCTL program: 
RESTART [server] 


Zero or more Names Server names separated by a space. When no 


arguments are supplied, only the current Names Server is restarted. 


RESTART is the same as STARTUP except that the Names Server is 
already running. 


Data is reloaded, statistics are reset, and all foreign data is flushed. 
Valid foreign cache data (that is, data with a TTL greater than 0) is 


retrieved from the checkpoint files. (The TTL value must be set to more 


than 0.) 


NAMESCTL> RESTART 
Confirm [yes or no]: yes 
Server restarted, 
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SET DEFAULT_DOMAIN 


SET EA ee o oeae 


Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Set or change the default domain for the NAMESCTL client. 
The NAMESCTL program must be loaded. 
No. 


From NAMESCTL program: 
SET DEFAULT_DOMAIN domain_name 


one domain name 


The existence of the DEFAULT_DOMAIN parameter allows names to be 
partially entered for names in that domain. For example, with 
DEFAULT_DOMAIN set to US.ACME the global name WIDE.US.ACME 
could be queried using: 


NAMESCTL> QUERY WIDE 
The initial value of DEFAULT_DOMAIN is set when the NAMESCTL 


program is started from the NAMES.DEFAULT_DOMAIN parameter in 
the SQLNET.ORA file. 


When no arguments are specified, the default is read and assigned from 
the client’s SQLNET.ORA file. 


SET DEFAULT_DOMAIN could be used to simplify working on a set of 
names within a single domain, then a set in another. 


NAMESCTL> SET DEFAULT_DOMAIN US.ACME 
Default domain is now "US.ACME” 
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SET FORWARDING_AVAILABLE 





Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Restrictions: 


Usage Notes: 


Example: 


Turns on or off name request forwarding for a Names Server. 
Names Server must be running. 
Yes, 


From the operating system: 


NAMESCTL SET FORWARDING_AVAILABLE OFF 


From NAMESCTL program: 
SET FORWARDING, AVAILABLE OFF 


Time is in one of the following formats: 
[ION | OFF] [YES|NO]] 


Default value: 0 (ON) 


This setting is intended only for Names Servers that have no local clients 
and are exclusively handling requests from foreign Names Servers. This 
usually would only apply to Names Servers in the root region when the 
root is configured without clients or services. If such a server is a 
performance bottleneck in cross-region request processing then 
disabling forwarding in that Names Server will cut its workload in half. 
Rather than forward the request and return the answer the Names 
Server simply tells the requestor the address of the Names Server that 
can answer the request. Note that there is no overall reduction in work; 
the work is simply displaced from the non-forwarding Names Server to 
the requesting Names Server. 


WARNING: If FORWARDING. AVAILABLE is set to off, any clients 
who rely directly on that Names Server will be unable to resolve foreign 
names. Clients are not capable of redirecting their requests as Names 
Servers would. Their requests will fail at that point, even if other Names 
Servers are listed in the NAMES.PREFERRED_SERVERS configuration 
parameter. 


NAMESCTL> SET FORWARDING_AVAILABLE OFF 
Request processing is now disabled. 
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SET LOG_STATS_INTERVAL 





Purpose: Changes the frequency with which the statistics are logged to the log 
file. 


Prerequisites: None. 
Password Required: Yes. 


Syntax: From the operating system: 
NAMESCTL SET LOG_STATS_INTERVAL time 
From NAMESCTL program: 
SET LOG_STATS_INTERVAL time 


Arguments: Time is in one of the following formats: 


<seconds> 
[<n> DAY[S]] [<hh>:<mi>:<ss>] 


For example, to increase the LOG_STATS_ INTERVAL to 36 hours, either 
of the following will work: 


SET LOG_STATS_INTERVAL 129600 
SET LOG_STATS_INTERVAL 1 DAY 12:00: 00 


You can specify any valid combination, such as the number of days 

combined with number of hours, minutes, and seconds; or just the 

number in hours (and not specify the number of days). 
Restrictions: © ‘Minimum Value: 10 seconds 

Maximum Value: no maximum 

Special Value: 0 (which means never reset) 

Default value: 0 (no logging) 

Usage Notes: The LOG_STATS_INTERVAL value is initially set based on the value 
configured in the Oracle Network Manager, or the value in 
NAMES.LOG_STATS_INTERVAL in the SQLNET.ORA file when the 
Names Server is loaded. By default, the value is 0 (no logging). This 
command is intended to override that value during server operation. 

Example: 


WAMESCTL> SET LOG_STATS_INTERVAL 7200 
Statistic counter logging interval is now 2 hours 
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SET NAMESCTL_TRACE_LEVEL 





Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Sets the level at which the NAMESCTL program can be traced. 
None. 
Yes. 


From the operating system: 

NAMESCTL SET NAMESCTL_TRACE_LEVEL [OFF | user | admin] 
From NAMESCTL program: 

SET NAMESCTL_TRACE_LEVEL [OFF |user | admin] 


OFF, USER, or ADMIN 


Tracing assists in diagnosing unexpected or unidentifiable failures in 
processing the NAMESCTL program. Tracing writes a series of events 
from normal NAMESCTL processing to.an operating system file for 
review by the administrator. 


Tracing output is at three levels OFF (none), USER (basic information), 
or ADMIN. 


When no arguments are supplied, the setting is reset to the value in the 
client's SQLNET.ORA file. The default setting is OFF. 


NAMESCTL> SET NAMESCTL_TRACE_LEVEL ADMIN 


Controller’s local trace level changed from 0 to 4 
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SET PASSWORD 


Purpose: 


Prerequisites: 


Password Required: 
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Syntax: 


Arguments: 


Usage Notes: 


Example: 





Register the password for privileged Names Server operations such as 
RELOAD and STOP. 


The NAMESCTL program must be loaded. 
N/A 


From NAMESCTL program: 
SET PASSWORD [password] 


Text string matching the value stored in the current Names Server 
parameter NAMES.PASSWORD. 


SET PASSWORD does not change the Names Server’s password. It 
simply sets a NAMESCTL environment variable that is compared to the 
value configured for the Names Server. If they match, operations 
requiring passwords are allowed. 


Only “privileged” operations are affected, that is, operations that alter 
the functioning of the Names Server. Operations such as SHOW or 
STATUS are not considered privileged, and do not require a password. 


The password can either be passed as an argument of the SET 
PASSWORD command, or if no argument is given, it will be prompted 
for. Note that the input is not displayed on the screen as itis typed. 


When passed over the network the password is ALWAYS encrypted, 
regardless of how it is set. 


NAMESCTL> SET PASSWORD OPEN_SESAME 
NAMESCTL> SET PASSWORD 
Enter name server password: 
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SET REQUESTS_ENABLED 


Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 





Determine whether the current Names Server will respond to requests. 


None. 

Yes. 

From the operating system: 

NAMESCTL REQUESTS_ENABLED [ON|OFF] 


From NAMESCTL program: 
SET REQUESTS_ENABLED [ON|OFF] 


ON or OFF 


Setting this property to OFF will send refusals to all clients that 
approach with Names requests. This is primarily useful for diagnostics 
when a Names Server is functioning unexpectedly. 


NAMESCTL> SET REQUESTS ENABLED OFF 
Confirm [yes or no]: yes 
General request processing is now disabled 
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SET RESET_STATS_INTERVAL 


Purpose: 


Prerequisites: 


Password Required: 
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Syntax: 


Arguments: 


Restrictions: 


Usage Notes: 


Example: 


Changes the time between the statistics being reset to zero or initial 
values in the current server. 


None. 
Yes. 


From the operating system: 

NAMESCTL SET RESET_STATS_INTERVAL time 
From NAMESCTL program: 

SET RESET_STATS_INTERVAL time 


Time is in one of the following formats: 
seconds 


[n DAY[S]] [hh:mi:ss] 


For example, to increase the RESET_STATS_INTERVAL to 72 hours, 
either of the following will work: 

SET RESET _STATS_INTERVAL 259200 

SET RESET_STATS_INTERVAL 3 DAYS 


Minimum Value: 10 seconds 
Maximum Value: no maximum 


Default value: 0 (never reset) 


The RESET_STATS_INTERVAL value is initially set based on the 
NAMES.RESET_STATS_INTERVAL parameter when the Names Server 
is loaded. This command is intended to override that value during 
Names Server operation. 


If the Stats Log Interval parameter in Network Manager is set to 0 (or if 
LOG_STATS_INTERVAL is set to 0), statistics are never written to the 
log file; they are kept in memory, and can be displayed by using the 
SHOW LOG_STATS_INTERVAL command. 


NAMESCTL> SET RESET_STATS_INTERVAL 1 DAY 
Statistic counter reset interval is now 24 hours 
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SET SERVER 





Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Change the current Names Server. 
The NAMESCTL program must be loaded. 
No. 


From NAMESCTL program: 


SET SERVER [server_name or server_address] 


valid server name or valid server address 


SET SERVER allows switching between multiple Names Servers while 
running the NAMESCTL utility. The qualifier can be a name where the 
name is defined in the memory of the current Names Server, or it can be 
the TNS address of any Names Server. 


The Names Server name specified is resolved through the current 
Names Server. Another Names Server can only be set if the current 
Names Server knows or can retrieve its address. If no current Names 
Server is set, you must type a TNS address to complete this command. 
IF there are no arguments, use NAMES.PREFERRED_SERVERS or try 
the well-known Names Server. 


NAMESCTL> SET SERVER. SERVER1.US.ACME 
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SET TRACE_LEVEL 





Purpose: Changes the TRACE LEVEL for tracing the current Names Server. 
Prerequisites: | None. 
Password Required: Yes. 


Syntax: From the operating system: 
NAMESCTL SET TRACE_LEVEL [OFF/user/admin] 
From NAMESCTL program: 
SET TRACE_LEVEL (OFF/user/admin] 


Arguments: One of OFF, USER, or ADMIN 


Usage Notes: Tracing assists in diagnosing unexpected or unidentifiable failures in 
processing the current Names Server. Tracing writes a series of events 
from normal Names Server processing to an operating system file for 
review by the administrator. 


Tracing output is at three levels OFF (none), USER (basic information), 
or ADMIN (maximum amount of information). 


After the TRACE_LEVEL is set, tracing begins immediately. All 
operations are traced until it is reset to trace level OFF. 


Trace files can grow very large. Remember to turn trace level off after 
diagnosing the problem. 
Example: 


NAMESCTL> SET TRACE_LEVEL ADMIN 
Trace level is now 6. 
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SHOW CACHE CHECKPOINT INTERVAL 


Purpose: 


Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Shows the frequency with which the Names Server's cache is written to 
the checkpoint file. 


None. 
No. 


From the operating system: 

NAMESCTL SHOW CACHE_CHECKPOINT_INTERVAL 
From NAMESCTL program: 

SHOW CACHE_CHECKPOINT_INTERVAL 


None. 


The CACHE_CHECKPOINT_INTERVAL is initially set with the value in 
NAMES.CACHE_CHECKPOINT_INTERVAL in the NAMES.ORA file, 
which was entered using Network Manager. By default, the value is 0, 
whci disables cache_checkpoint. Data written to the cache checkpoint 
file includes service names and addresses, and Names Server addresses 
which werelearned by the Names Server as a result of forwarding a 
query to a foreign region on behalf of the client. 


NAMESCTL> SHOW CACHE_CHECKPOINT_INTERVAL 
Cache checkpoint interval is currently 8 minutes 20 
seconds 
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SHOW FORWARDING_AVAILABLE 


Purpose: 


Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Shows whether the Names Server is forwarding requests for foreign 
names or redirecting them. 


None. 
No. 


From the operating system: 


NAMESCTL SHOW FORWARDING_AVAILABLE 
From NAMESCTL program: 
SHOW FORWARDING_AVAILABLE 


Zero or more Names Servers separated by a space. If no names are 
given, then the setting is displayed for the current server. 


By default, all Names Servers forward requests for foreign names. If 
forwarding is disabled, then requests for foreign names will be 
redirected to a Names Server in the region which is authoritative to the 
requested name. 


Disabling forwarding can reduce the load on a particular server, and 
will also make it impossible for direct clients of that server to resolve 
foreign names. Clients cannot be redirected, only ohter Names Servers. 
See also SET FORWARDING_AVAILABLE. 


NAMESCTL> SHOW FORWARDING, AVAILABLE 
Request forwarding is currently enabled 
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SHOW DEFAULT_DOMAIN 


Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Display the default domain for the NAMESCTL client. 


None. 
No. 


From the operating system: 


SHOW DEFAULT „DOMAIN 


From NAMESCTL program: 
SHOW DEFAULT_DOMAIN 


None. 


The existence of the DEFAULT_DOMAIN parameter allows names to be 
partially entered for names in that domain. For example, with 
DEFAULT_DOMAIN set to ACME.WORLD the global name 
WIDE.ACME.WORLD could be queried using: 


NAMESCTL> QUERY WIDE 


The initial value of DEFAULT_DOMAIN is set when the NAMESCTL 
program is started from the NAMES.DEFAULT_DOMAIN parameter in 
the SQLNET.ORA file. 


SHOW DEFAULT_DOMAIN is used when the user is unsure of the 
current default domain, or wants to know the default for the current 
configuration. 





NAMESCTL> SHOW DEFAULT_DOMAIN 
Current default domain is “world” 
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SHOW LOG_FILE_NAME 
a = aara aaa aaar a UU 


Purpose: 


Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Shows the name of the file where the Names Server writes the logging 
information. 


None 
No 


From the operating system: 
NAMESCTL SHOW LOG_FILE_NAME 


From NAMESCTL program: 
SHOW LOG_FILE_NAME 


none 


The LOG_FILE_NAME is initially set with the value in 
NAMES.LOG_FILE_NAME in the NAMES.ORA file, which is entered 
using the Network Manager. The default value is platform-specific, but 
is typically NAMES.LOG and is located in the network/log subdirectory 
during Oracle installation. This file must be writable to the Names 
Server. 


NAMESCTL> SHOW. LOG_FILE_NAME 
Log file name is currently 
/private/ora23/network/names.log 
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SHOW LOG_STATS_INTERVAL 


. Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Displays the frequency with which the statistics are logged to the logfile. 
None. 

No. 

From the operating system: 

NAMESCTL SHOW LOG_STATS_INTERVAL 


From NAMESCTL program: 
SHOW LOG_STATS_INTERVAL 


Zero or more Names Servers separated by a space. If no names are 
given, then the setting is displayed for the current server. 


The LOG_STATS_INTERVAL is initially set with the value in 
NAMES.LOG_STATS_INTERVAL in the NAMES.ORA, file, which is 
entered using the Network Manager. By default, the value is 0, or no 


logging. 
If the value is specified from the Network Manager, or from 


NAMESCTL SET LOG_STATS_INTERVAL, the Names Server will write 
a set of internal statistics to its log file with the specified frquency. 


NAMESCTL> SHOW LOG_STATS_INTERVAL 
Statistic counter logging is currently disabled 
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SHOW NAMESCTL_TRACE_LEVEL 


Purpose: 


Prerequisites: 


Password Required: 
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Syntax: 


Axyguments: 


Usage Notes: 


Example: 


Displays control of the level at which the NAMESCTL program is being 
traced. 


None. 
No. 


From the operating system: 

NAMESCTL SHOW NAMESCTL_TRACE_LEVEL 
From NAMESCTL program: 

SHOW NAMESCTL_TRACE_LEVEL 


None. 


Tracing assists in diagnosing unexpected or unidentifiable failures in 
processing the NAMESCTL program. Tracing writes a series of events 
from normal NAMESCTL processing to an operating system file for 
review by the administrator. 


‘Tracing output is at three levels OFF (none), USER (basic information), 
or ADMIN (maximum amount of information). 

SHOW NAMESCTL_TRACE_LEVEL is the only guaranteed source of 
what the current tracing level is. Even if 
NAMES.NAMESCTL_ TRACE, LEVEL is configured in the Network 
Manager or the SQLNET.ORA configuration file, a previous call from 
the NAMESCTL program may have overridden it. 


NAMESCTL> SHOW NAMESCTL__TRACE_LEVEL 
Controller's trace level is currently 0 
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SHOW REQUESTS_ENABLED 


Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 





Shows whether or not the Names Server is responding to requests. 
None, 
No. 


From the operating system: 


NAMESCTL SHOW REQUESTS_ENABLED 


From NAMESCTL program: 
SHOW REQUESTS_ENABLED 


Zero or more Names Servers separated by a space. If no names are 
given, then the setting is displayed for the current server. 


If REQUESTS_ENABLED is off, all requests to the Names Server will be 
refused. This parameter is intended for diagnostic purposes only. 


NAMESCTL> SHOW REQUESTS_ENABLED 
General request processing is currently enabled. 
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SHOW RESET_STATS_INTERVAL 





Purpose: 


Prerequisites: 


Password Required: 
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Syntax: 


Arguments: 


Usage Notes: 


Example: 


Shows whether or not the Names Server is responding to requests. 
None. 


No. 


From the operating system: 


NAMESCTL SHOW RESET_STATS_INTERVAL 


From NAMESCTL program: 
SHOW RESET_STATS_INTERVAL 


Zero or more Names Servers separated by a space. If no names are 
given, then the setting is displayed for the current server. 


If RESET_STATS_INTERVAL is initially set with the value in 
NAMES.RESET_STATS_INTERVAL in the NAMES.ORA file using the 
Network Manager. By default the value is set to 0, or no reset. This 
results in the Names Server accumulating statistics the entire time it 
runs. For example, if statistics are reset every day, then the statisitcs will 
represent totals for the day rather than the entire time the server has 
been running. 


NAMESCTL> SHOW RESET_STATS_INTERVAL 
Resetting of statistic counters is currently disabled 
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SHOW SERVER 





Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 





Display the current Names Server. 


None 

No 

From the operating system: 
NAMESCTL SHOW SERVER 


From NAMESCTL program: 
SHOW SERVER 


None. 


SHOW SERVER displays the current Names Server that commands will 
operate on. 


NAMESCTL> SHOW SERVER 
currently managing name server "NameServer.us.oracle.com 
version Banner is "Oracle Names for SunOS: Version 2.0.0.0" 
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SHOW STATUS 





Password Required: 
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Purpose: 


Prerequisites: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Display the general status information about the Names Server. 
None 
No 


From the operating system: 
NAMESCTL SHOW STATUS 
From NAMESCTL program: 
SHOW STATUS 


Zero or more Names Servers separated by a space. If no names are 
given, then the setting is displayed for the current server. 


Shows the current state of a Names Server. 
Identical to the command STATUS, 


NAMESCTL> SHOW STATUS 

Version Banner is "Oracle Names for SunOS: Version 2.0.0.0" 
Server has been running for: 1 day 2 hours 3 minutes 35.16 
seconds 
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SHOW SYSTEM_QUERIES 





Purpose: 


Prerequisites: 


Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Display the next occurrence of all system queries. 


This is only relevant for distributed configurations. There are no system 
queries with only one administrative region. 


No. 


From the operating system: 
NAMESCTL SHOW SYSTEM_QUERIES 
From NAMESCTL program: 

SHOW SYSTEM_QUERIES 


None. 


System queries are performed at intervals to keep information among 
Names Servers current. 


There is no specific action that can change the activities listed as system 
queries. Being able to show them gives the administrator an 
understanding of when a system change will occur, and may assist in a 
decision to RESTART, thus forcing system. data to be reloaded sooner. 


NAMESCTL> SHOW SYSTEM_QUERIES 


System query index number: di 
Query ID: 49824 
Query next issued in: 2 hours 55 min 3.84 seconds 
Query state: 2 
Name: uy 
Desired data type: ns.smd 
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SHOW TRACE_FILE_NAME 


SHOW TRACSIN Ee o o oo o mamase 


Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Displays the TRACE_LEVEL for tracing the current Names Server. 
None 
No 


From the operating system: 

NAMESCTL SHOW TRACE_FILE_NAME 
From NAMESCTL program: 

SHOW TRACE_FILE_NAME 


None. 


The TRACE_FILE_NAME is initially set with the value in the 
NAMES.TRACE_FILE_NAME in the NAMES.ORA file, using Network 
Manager. The default value is platform-specific, but is typically 
NAMES.TRC and is located in the network/trace subdirectory during 
the Oracle installation. This file must be a valid filename, and the file 
must be writable to the Names Server. 


This file is only used if tracing is enabled using the 
NAMES.TRACE_LEVEL. 


NAMESCTL> SHOW TRACE_FILE_NAME 
Trace file name is currently 
/private/ora23/network/names tre 
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SHOW TRACE_LEVEL | 
Purpose: Displays the TRACE LEVEL for tracing the current Names Server. 


Prerequisites: None. 


Password Required: No. | 





Syntax: From the operating system: | 
NAMESCTL SHOW TRACE_LEVEL i 


From NAMESCTL program: 
| SHOW TRACE_LEVEL | 


Arguments: None. 


| Usage Notes: Tracing assists in diagnosing unexpected or unidentifiable failures in 
processing the current Names Server. Tracing writes a series of events 

| from normal Names Server processing to an operating system file for 

review by the administrator, | 


Tracing output is at three levels OFF (none), USER (basic information), 
or ADMIN (maximum amount of information). 


SHOW TRACE_LEVEL is the only guaranteed source of what the i 
current tracing level is. Even if the TRACE_LEVEL is configured in the i 
i Oracle Network Manager or the SQLNET.ORA configuration file, a 

l previous call from the NAMESCTL program may have overridden it, 





| Example: 


NAMESCTL> SHOW TRACE LEVEL 
Trace level is currently 0 
i 
| 
ji 
| 
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SHOW VERSION 





Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Displays the TRACE_LEVEL for tracing the current Names Server. 
None 

No 

From the operating system: 

NAMESCTL SHOW VERSION 


From NAMESCTL program: 
SHOW VERSION 


Zero or more Names Servers separated by a space. If no names are 
given, then the setting is displayed for the current server. 


This banner identifies the server by name and version. This can be 
useful when clearing up minor difficulties. This command is enabled 
every time you connect NAMESCTL to a server. 


NAMESCTL> SHOW VERSION 

Currently managing Names Server “NameServer .world” 
version banner is “Oracle Names for SunOS: Version 
2.0.0.0.0" 
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SHUTDOWN 





Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Stops one or more Names Servers. 
Names Server must be started. 
Yes 


From the operating system: 


NAMESCTL SHUTDOWN [server] 


From NAMESCTL program: 
SHUTDOWN [server] 


Zero or more Names Server names separated by a space. When no 
arguments are supplied, only the current Names Server is shut down. 


SHUTDOWN stops the current Names Server and unloads the program 
from memory. A Names Server should only be shut down for 
operational reasons like upgrades or machine maintenance. The 
preferred way to stop and start a Names Server is using the RESTART 
command because you can perform it from anywhere in the network. If 
SHUTDOWN and START are processed individually, they must occur 
on the Names Server machine. 


SHUTDOWN is identical to STOP. 


NAMESCTL> SHUTDOWN 
Confirm [yes or no] yes 
Server shut down. 
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START 





Purpose: Loads the Names service program and starts loading system and local 
administrative region data. 


Prerequisites: | Names Server must be stopped. 
Password Required: No 


Syntax: From the operating system: 
NAMESCTL START 
From NAMESCTL program: 


NAMESCTL> START names.parameter = value 


Arguments: None. 


Usage Notes: START is the command used to initially load a Names Server into 
memory. At startup, the Names Server reads its configuration files to set 
up its operating parameters, then loads all data for the administrative 
region. 


Security on Names Server startup is supplied through the operating 
system Names is installed on. Because Names must be started from a 
local session, network security is not an issue. See the Oracle installation 
manual for your platform for more details. 


START is identical to STARTUP. 


Example: 


Starting "/oracle/bin/names”...server successfully started 
Currently managing name server "NSERVER.world” 


Version banner is "Oracle Names for SunOS: Version 


2.0.0.0.0" 

Server name: NSERVER .world 
Server has been running for: 0.86 seconds 
Request processing enabled: yes 

Request forwarding enabled: no 

Requests received: 0 

Requests forwarded: 0 

Data items cached: 0 
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Region data next checked for reload: 
3 hours 59 minutes 59.77 seconds 


Region data reload check failures: 0 
Cache next checkpointed in: not set 
Cache checkpoint interval: not set 


Cache checkpoint file name: 
/oracle/network/names/cch003£4.ora 


Statistic counters next reset in: not set 
Statistic counter reset interval: not set 
Statistic counters next logged in: not set 


Statistic counter logging interval: not set 
Trace level: 0 
Trace file name: 

/oracle/network/trace/names.tre 
Log file name: 

/oracle/network/log/names.log 
System parameter file name: 

/ovacle/network/admin/names,.ora 
Command-line parameter file name: an 
Administrative region name: LOCAL_REGION 


Administrative region description: /netadmin/inttest2.net 
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STARTUP 





Purpose: 


Prerequisites: 


Password Required: 
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Syntax: 


Arguments: 


Usage Notes: 


Example: 


Loads the Names service program and starts loading system and local 
administrative region data. 


Server must be stopped. 
No 


From the operating system: 


NAMESCTL STARTUP names.parameter = value 


From NAMESCTL program: 


NAMESCTL> START names.parameter = value 
None 


STARTUP is the command used to initially load a Names Server into 
memory. At startup, the Names Server reads its configuration files to set 
up its operating parameters, then loads all data for the administrative 
region. 

Security on Names Server startup is supplied through the operating 
system Names is installed on. Because Names must be started from a 


local session, network security is not an issue. See the Oracle installation 
manual for your platform for more details. 


STARTUP is identical to START. 


NAMESCTL> START 
Starting ”"/oracle/bin/names”...server successfully started 


Currently managing name server “NSERVER.world” 
Version banner is “Oracle Names for SunOS: Version 
2.0.0.0.0" 


Server name: NSERVER. world 
Server has been running for: 0.86 seconds 
Request processing enabled: yes 

Request forwarding enabled: no 

Requests received: 0 

Requests forwarded: 0 

Data items cached: 0 
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Region data next checked for reload: 
3 hours 59 minutes 59.77 seconds 


Region data reload check failures: 0 
Cache next checkpointed in: not set 
Cache checkpoint interval: not set 


Cache checkpoint file name: 
/oracle/network/names/cch003f4.ora 


Statistic counters next reset in: not set 
Statistic counter reset interval: not set 
Statistic counters next logged in: not set 


Statistic counter logging interval: not set 
Trace level: 0 
Trace file name: 

/oracle/network/trace/names.tre 
Log file name: 

/oracle/network/log/names.log 
System parameter file name: 

/oracle/network/admin/names.ora 
Command-line parameter file name:’” 
Administrative region name: LOCAL, REGION 
Administrative region description: /netadmin/inttest2.net 


See STATUS for more information after you start the Names Server. 
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STATUS 





Purpose: Displays statistics for one or more Names Servers as well as many of its 
internal settings. 


Prerequisites: | Names Server must be started. 
Password Required: No. 


Syntax: From the operating system: 
NAMESCTL STATUS [server] 
From NAMESCTL program: 
STATUS [server] 
Arguments: Zero or more Names Server names separated by a space. When no 


arguments are supplied, status is given only for the current Names 
Server. 


Usage Notes: STATUS shows the activity of the Names Server over time and its state 
ata point in time. 
Example: 


NAMESCTL> STATUS 
Version banner is “Oracle Names for SunOS: 


2.0.0.0.0” 
Server name: NSERVER. world 
Server has been running for: 1 day 20 hours 
59 minutes 
48.06 seconds 
Request processing enabled: yes 
Request forwarding enabled: no 
Requests received: 16 
Requests forwarded: 0 
Data items cached: 0 


Region data next checked for reload: 
3 hours 59 minutes 35.61 seconds 


Region data reload check failures: 0 
Cache next checkpointed in: ~ not set 
Cache checkpoint interval: not set 


Cache checkpoint file name: 
/oracle/network/names/cch003f4.ora 
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Statistic counters next reset in: not set 
Statistic counter reset interval: not set 
Statistic counters next logged in: not set 
Statistic counter logging interval: not set 
Trace level: 12 
Trace file name: 

/oracle/network/trace/names.trce 
Log file name: 

/oxracle/network/log/names.log 
System parameter file name: 

/oracle/network/admin/names.ora 


nn 


Command-line parameter file name: 


Administrative region name: LOCAL_REGION 
Administrative region description: /netadmin/inttest2.net 
Apple Table Index 0 

Contact 0 

Operational Status 0 
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STOP 





Password Required: 


Aw 52 


Purpose: 


Prerequisites: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Stops one or more Names Servers. 
Names Server must be started. 
Yes 

From the operating system: 
NAMESCTL STOP [server] 


From NAMESCTL program: 


STOP [server] 


Zero or more Names Server names separated by a space. When no 
arguments are supplied, only the current Names Server is stopped. 


STOP stops the current Names Server and unloads the program from 
memory. A Names Server should only be shut down for operational 
reasons like upgrades or machine maintenance. The preferred way to 


stop and start a Names Server is using the RESTART command because 
you can issue it from anywhere in the network. If STOP and START are 
processed individually, they must occur on the Names Server machine. 


STOP is identical to SHUTDOWN. 


NAMESCTL> STOP 
Confirm [yes or no]: yes 
Server shut down 
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TIMED_QUERY (Dynamic Discovery Option Only) 





Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 





Show all registered data in the Names Server cache. 
None 
No 


From the operating system: 
NAMESCTL TIMED_QUERY 


From NAMESCTL program: 


timed_query [time] (for release 2.3.2 and later) 
None at this time. 


With this release, the timed_query simply returns all objects that have 
been registered automatically by the listener or manually through 
NAMESCTL. Data which was loaded from a network definition 
(generated by Network Manager) is not included. The time argument is 
supported which will return all objects registered after a given time. 


NAMESCTL> timed_query 
Oracle Names Control for SVR4: Version 2.0.0.0.0 - 
Beta on 31-AUG-95 16:35:15 
Copyright (c) Oracle Corporation 1993. All rights 
reserved. 
Currently managing name server "NS'7DLAA9” 
Version banner is “Oracle Names for SVR4: Version 
2.0.0.0.0" 
Total response time: 0.08 seconds 
Response status: normal, successful completion 
Name: [root] 

data type is “ns.smd” 

Syntax is DOMAIN: NS7D1AA9 
Name: NS7D1Aa9 

data type is "“a.smda” 

Syntax is ADDR: 

. .. (ADDRESS= (PROTOCOL=tep) (HOST=oranamesrvr1) (PORT 
=1575)) 
Name: listenerl 
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data type is “a.smd” 

Syntax is ADDR: 

_ .. (WDESCRIPTION= (ADDRESS_LIST= (ADDRESS= (PROTOCOL=i 
pe) (DEV=7) (KEY=blackwidowl .world) ) (ADDRESS= (PROTOCOL= 
tcp) (DEV=11) (HOST=139.185.22.22) (PORT=1520))) (CONNECT 
_DATA= (SID=reltest) )) 

data type is “tos.npd.omd” 

Syntax is CTEXT: “listener” 

Name: rl.worlid 

data type is “a.smd” 

Syntax is ADDR: 

_. . (DESCRIPTION= (ADDRESS_LIST= (ADDRESS= (PROTOCOL=i 
pe) (DEV=7) (KEY=blackwidowl .world) ) (ADDRESS= (PROTOCOL= 
top) (DEV=11) (HOST=139.185.22.22) (PORT=1520))) (CONNECT 
_DATA=(SID=reltest))) 

data type is “tos.npd.omd” 

Syntax is CTEXT: “database” 

Last timestamp: 12201913 
This shows newly registered data since 12201913 
NAMESCTL> TIMED_QUERY 12201913 
Name: listener2 

data type is “a.smd” 

Syntax is ADDR: 

_. . (DESCRIPTION= (ADDRESS_LIST= (ADDRESS= (PROTOCOL=i 
pe) (DEV=7) (KEY=blackwidowl . world) ) (ADDRESS= (PROTOCOL= 
top) (DEV=11) (HOST=139.185.22.22) (PORT=1520))) (CONNECT 
_DATA=(SID=reltest) )) 

data type is "“tos.npd.omd” 

Syntax is CTEXT: "listener” 

Name: rl.world 

data type is "a.smd” 

Syntax is ADDR: 

_. . (DESCRIPTION= (ADDRESS_LIST= (ADDRESS= (PROTOCOL=i 
pe) (DEV=7) (KEY=blackwidowl .world) ) (ADDRESS= (PROTOCOL= 
top) (DEV=11) (HOST=139.185.22.22) (PORT=1520) ) ) (CONNECT 
_DATA= (SID=reltest) )) 

data type is "“tos.npd.omd” 

Syntax is CTEXT: “database” 

Last timestamp: 12211915 
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UNREGISTER (Dynamic Discovery Option Only) 





Purpose: 
Prerequisites: 
Password Required: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


To remove a network object from a Names Server. 
None 
No 


From the operating system: 
NAMESCTL UNREGISTER OBJECT_NAME 


From NAMESCTL program: 
UNREGISTER OBJECT_NAME 


Mandatory object name. 


Provides a manual mechanism for unregistering a service. The definition 


for that object is removed from the well known Names Server and all 


other well known Names Servers in the region. 


NAMESCTL> UNREGISTER PARTS 
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VERSION 





Password Required: 


A-56 


Purpose: 


Prerequisites: 


Syntax: 


Arguments: 


Usage Notes: 


Example: 


Displays the TRACE_LEVEL for tracing the current Names Server. 
None 
No 


From the operating system: 


NAMESCTL VERSION 


From NAMESCTL program: 
VERSION 


Zero or more Names Servers separated by a space. If no names are 
given, then the setting is displayed for the current server. 


This banner identifies the server by name and version. This can be 
useful when clearing up minor difficulties. This command is enabled 
every time you connect NAMESCTL to a server. 


NAMESCTL> VERSION 

Currently managing Names Server “NameServer .world” 
version banner is "Oracle Names for SunOS: Version 
2.0.0.0.0" 
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APPENDIX 


Complex Network 
Issues and DDO 


T his appendix covers complex network issues that are relevant to 
configuring and managing Oracle Names 2.0 with the Dynamic 
Discovery Option. 


Because Oracle does not recommend using the Dynamic Discovery 
Option on complex networks, this appendix is a reference, or 
informational chapter to be used by administrators who are exploring 
the possibility of upgrading a complex network to Oracle Names 2.0 
with the Dynamic Discovery Option. 


Note: If you are gradually upgrading your network to use 
DDO, when you finally upgrade to a complete network that 
uses DDO, it will be necessary to perform additional manual 
administration steps to ensure your network is a pure DDO 
network. 


Complex Network Issues and DDO Bel 


The Function of Network Components 


When you configure and run a network with Oracle Names 2.0 and the 
Dynamic Discovery Option, there are three main network components 
that must be able to communicate and find each other: 


e Names Servers—The Names Servers on the network using DDO must 
know about each other. In a network using the DDO, each new 
Names Server finds other Names Servers at well-known Names 
Server addresses. 


e Oracle7 Servers—Oracle7 Servers must know how to find a Names 
Server in order to register themselves automatically. If they are not 
registered automatically, they need to be defined in the network 
definition using Network Manager. 


e Clients—Clients on the network must know how to find the Names 
Servers. 


EA 
Constraint Issues 


This appendix discusses the following complex network issues: 


e Local backward compatibility constraints — issues that arise 
within the local region, when you are mixing versions of Oracle 
Names and SQL*Net 


e Community constraints -constraints that need to be considered 
when you configure a network with the DDO with more than one 
community 


e Multiple region constraints-using Oracle Names 2.0 with the 
DDO ina complex network with multiple regions 


Note: Remember, if you have a network that stays the same for 
long periods of time, whether large or small, converting the 
network to the DDO may not be worth the effort. 
Administrators of networks might find the Dynamic Discovery 
Option more troublesome to use than its benefits warrant. 
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The following table illustrates further compatibility issues when you are 
considering upgrading a complex network. 


In Order for... You Need to Do One of the Following... 


the client to be able to find the Names Server -Assign a well-known Names Server address 





















-Configure a Names Service address in the 
NAMES.PREFERRED_SERVER parameter in 
the SQOLNET.ORA file. 


-automatic registration using the listener 









the database name and address to be provided 
to the Names Server 





-enter the databases name and address into the 
network definition using Network Manager 









~manual registration of the service using 
NAMESCTL 


-Assign a well-known Names Server address 









Names Server name and address to find the 
well-known Names Server 






-enter the Names Server name and address us- 
ing Network Manager 














-manual registration of the service using 
NAMESCTL 


~enter the addresses into the network definition 
using Network Manager 

















the addresses of all Names Servers from certain 
foreign regions to to be known to local Names 
Servers, therefore ensuring Names Server 


topology 







Points to Remember 


e When anew Names Server enters a region, that new Names 
Server needs to find an existing well-known Names Server. When 
the new Names Server finds the existing well-known Names 
Server, it downloads the current cache information from the 
existing well-known Names Server and registers itself to all 
well-known Names Servers in that region, based on the cache 
information that it was given when it downloaded. 


« Each region cache in a multi-region network must know about all 
of the Names Servers in all of its own subregions, along with the 
ROOT region. 


ə Manually configuring a multi-region network is not advised for 
DDO. If your network is that complex, you might find the DDO 
more troublesome to use than its benefits warrant. 
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Local Backward Compatibility Constraints 


B-4 


You must determine whether your network has any local backward 
compatibility constraints. Read this section if your network includes 
clients and servers using earlier releases of SQL*Net and Oracle7. These 
rules tell you whether you can use a well-known Names Server. 


The following must all be true, regardless of the underlying community. 
structure: 


all local Names Servers are upgraded to 2.3 


This means that Names Servers will work even if the region spans 
multiple communities. As long as the network definition is 
necessary for pre~2.3 support, there will be no community issues 
to resolve. 


New Oracle Names Servers must also be defined in the network 
definition as long as there are SQL*Net 2.2 (or earlier) clients on 
the network that have not been upgraded. 


The network definition is the source of the 
NAMES.PREFERRED_SERVERS parameter in the SQLNET.ORA 
file, which the pre—2.3 clients use to find their Names Servers. 


Since all Names Servers must read the network definition, and all 
Names Servers are defined in the network definition, Names 
Servers do not need well-known Names Servers to know about 
each other. 


All Names Servers will continue touse the network definition 
because they must get information for 7.2 databases whenever the 
data is modified. 


New and upgraded Names Servers can use well-known 
addresses as long as the new well-known Names Servers are 
defined in the network definition using oranamesrvr0-4. 


Clients, databases, and listeners on an existing network already 
have a NAMES.PREFERRED_SERVERS defined in their 
SQLNET.ORA file enabling them to find all local Names Servers, 
regardless of whether they are using a well-known Names Server. 


These are configured addresses that are provided to Oracle 
Names clients, and SQL clients and listeners. They are also 
provided to other Names Servers in the network definition. 


When all SQL*Net 2.2, (or earlier) clients have been upgraded, the 
Names Server definitions can be dropped from the network 
definition. 
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In this case there must be at least one well-known Names Server 
and no community constraints. For more information on this 
issue, see “Community Constraints” later in this appendix. 


¢ When ail databases and listeners in the region are upgraded to 
Oracle 7.3, service information in the network definition can be 
dropped because services are now automatically registered. 


e When the previous two items are true, the network definition and 
the NAMES.PREFERRED_SERVERS can be dropped entirely. All 
of the Names Servers and all of the clients are now upgraded and 
the network definition is unnecessary in the Dynamic Discovery 
network. 


COES EN 
Community Constraints 


This section discusses community constraint issues within an existing 
hierarchy. 


A community is defined as the set of all machines that may be directly 
connected using a given transport protocol. Communities are generally 
joined by MultiProtocol Interchanges. 


In networks or regions which consist of multiple communities, the 
well-known Names Server mechanism is not sufficient to enable clients 
to find all local Names Servers. Therefore, it is necessary to maintain the 
NAMES.PREFERRED_SERVERS parameter in the SQLNET.ORA file 

| even if there are no local backward compatibility constraints. 


To enable Names Servers to find out about each other you must do one | 
of the following: 
H 
| 
| 
i 


e maintain the network topology data in the network definition 
or 


e manually “prime” the Names Server by using the NAMESCTL 
command to register another existing Names Server. 


After this is done, restart the Names Server using the 
NAMESCTL>STARTUP command. 





j 
| 
| 
| 
| 
| 
| 
| 
| 
| 
i 
| 
i 
| 


| 
\ 
f 
| 
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Multiple Region Constraints 


There are several constraint issues for networks with multiple regions 
that exist within a regional hierarchy: 


e New or additional Names Servers must be defined in any 
relevant multiple region network definition. 


If there are other regions (most likely SQL*Net 2.1 or 2.2 regions), 
the Names Servers in those region will need the new well-known 
Names Server address to forward queries to any Names Servers 
in those region. 


e There must be a local network definition that includes the 
network topology data describing the relevant multiple regions in 
that network. 


« If multiple regions exist in the same community, and the same 
TCP domain, then well-known Names Servers should not be 
used anywhere. 
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APPENDIX 








Advanced. Topics 


T his chapter discusses the following advanced topics in detail: 


Defining a client profile 

Delegating authority from a central administrative region 
Defining foreign regions 

Remote domains and Names Server hints 

Defining local and foreign domains in Network Manager 
How names are resolved in delegated administrative regions 


Defining objects in foreign domains 
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Defining a Client Profile 


All clients that belong to the same community, use the same 
Interchanges, and the same Names Servers can share a single client 
profile. Any variation requires a separate client profile. 


Administrator’s Role 


The administrator should advise each client as to which client profile is 
best suited to it. This takes basic planning of the network model in 
anticipation of how it will be used. As the details of the client profile 
change, the client must receive a new copy of the configuration files. 


Consider the example in the following figure. The naming model is a 
basic hierarchy of two domains (DD1 and DD2), administered as a 
single administrative region (RAR). The network has two communities 
(C1 and C2), two Interchanges (I1 and 12), and three Names Servers (N1, 
N2, and N3). 


Naming Model Root Administrative Region 






Root Domain 


`s 





Client1 OS Cliem2 
Client3 
Figure C- 1 Sample Client Profiles 
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Fully extrapolated, this could lead to a very large number of client 
profiles. Table C~1 lists the possible client profiles for the three clients 
shown in the following figure. 


Table C-1 Possible Client Profiles 


Table C-1 Communities Interchange Default Names Servers 
Domain 


Possible Client Client 1 





Profiles for Figure 





Client 2 























Client3 N1, N2, N3 
N1, N3, N2 
N2, N1, N3 
N2, N3, N1 
N3, N1, N2 
N3, N2, N1 
N1, N2, N3 
N1, N3, N2 
N2, N1, N3 
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Table C-1 Client Communities Interchange Default Names Servers 


N2, N3, N1 
N3, N1, N2 
N3, N2, N1 





This simple case can result in as many as 28 client profiles if you include 
all ”not-null” permutations. 


In practice, however, there are usually very few client profiles to 
describe all clients. The entire network shown may be serviced by 
having all clients be defined as: 


Table C ~2 Possible Client Definitions 














Table C-2 Client Communities Interchange Default Names Servers 


Actual Client Profiles | Client 1 
Used in Installation 


Client 2 














N1, N2, N3 


N2, N3, N1 


Each client could then be identified based on which of these six client 
profiles best fits its needs. Basic load balancing is achieved on the 
Interchanges and Names Servers by making the different domain 
members use different preferred Interchanges and Names Servers first. 
Client 3 does not require Interchange definitions because it can connect 
to all nodes directly on C1 or C2, and thus would never use the 
Interchange. 











During configuration, the SQL*Net administrator creates a default client 
profile for each of the communities and domains in the network. In 
many cases these are adequate for all clients sharing those properties. 


Synchronizing Clients 


The client profile consists of two configuration files— TNSNAV.ORA 
which defines the Interchange preferences, and SQLNET.ORA which 
defines the Names Servers preferences. 
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Physically, clients may each have a copy of the files, or they may share a 
copy mounted on a distributed file system such as PC LAN or Network 
File System (NFS). In the latter case, the administrator can handle all 
initial distribution and updates without any exposure to the user. When 
the clients have individual copies, there are many ways to distribute the 
files. See Oracle Network Manager Administrator’s Guide for information 
about distributing the configuration files. 


Pee OTST SS SENET 
Delegating Authority from a Central Administrative Region 
The example in Figure C-2 is an illustration of a central region 


delegating authority to two administrative regions—US and UK. This 
example is used throughout the following sections. 






Network Definition 
Database and 
Network Manager 


Figure C-2 A Central Region Using a Hierarchical Naming Model 


The tasks an administrator must perform to delegate authority to 
another region are: 
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+ Save and give a copy of the current network definition to the 
administrator of the delegated region. 


+ Decide which domains are going to be delegated. 


+ Delete any database/ listener definitions which are “owned” by 
the delegated region. 


e Mark the delegated domains as foreign in your network 
definition. 


+ Create a foreign region for each delegated region and allocate the 
delegated domains to those regions. 


The tasks a delegated region’s administrator must do in order to bring 
the definition in line with the “rest of the world” are: 


e Mark domains in his or her administrative region as local. 


+ Delete databases and listeners that are not in the local region. 


Mark all other domains not in the local region as foreign. 


Create a foreign region for the ROOT region. Add all the ROOT 
region’s domains into this region. 


Note: Each region’s administrator must have a separate version 
of the Network Manager in which to create or update the 
network definition. 


To delegate administrative authority from one single, central 
administrative region (using a hierarchical naming model) to two 
administrative regions, use the following procedures. 


Define the Local Region’s Name 
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Create the region name by appending one of the domains that the region 
contains onto the end of the region name. It doesn’t matter what 
domain name is appended to the region name, as long as it is one of the 
domains that reside in the region. By default, Network Manager puts 
the local region into the WORLD domain. For example, 
ROOT_REGION.ACME.COM would be an appropriate choice for this 
example. To define the name of the local region: 


Le 


Select Region on the Network Manager: Object List window, and 
select LOCAL_REGION.WORLD, then select Edit. Change the 
name of the local region to ROOT_REGION.ACME.COM. To do 
this, change the name to ROOT_REGION and select Choose to 
display a list of domains in this region, then choose ACME.COM. 
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Because ACME.COM is one of the domains in the root region, it can 
be used to create the region name; in this case, 
ROOT_REGION.ACME.COM. 


Note: If you are using a hierarchical naming model, it is | 
recommended that you select a domain name other than 
WORLD. 


After receiving a copy of the root region network definition, each of the 
delegated region administrators must update their network definitions | 
to reflect their new region names, for example, US_REGION and 
UK_REGION. | 


Mark Domains in Local Region. as Local | 


Each administrator must designate all domains in the local region as 
local. The root region must also do this after delegating authority to 
another region. | 


To mark domains in a local region as local: 


1. Select the Region property sheet from the Network Manager: Object 
List window. Make sure all domains within the local region are i 
listed in the Domains within Region list box. If necessary, go to the 
Domain property sheet for the domain, and make sure it is not | 
marked as a foreign item. | 


Delete Databases No Longer in the Local Region 





After receiving a copy of the network definition from the root region 
administrator, both the UK and the US administrators must delete 
databases and listeners that are not in their respective regions. Similarly, 
the root region administrator must delete databases and listeners that 
are no longer in the root region. 





To delete databases from the local region: 
1. Open the network definition for the local region. 


| 

2. Select the Database property sheet from the Network Manager: | 
Object List window. Delete all the listeners and databases no longer | 

in the local region. For example, the root administrator must delete | 

all databases in the US and UK region, the UK region must delete | 
databases in the root and US regions, and so forth. 


| 3. Upon deleting databases and listeners, messages display indicating 
that the database will be invalidated, and asking whether you want | 
to proceed. Select Yes, 
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There should no databases or listeners in any foreign regions in the 
local region’s network definition. 


Marking Domains Not in Local Region as Foreign Domains 


The root administrator must mark all delegated domains as foreign in 
the root region’s network definition. Similarly, the delegated 
administrators must mark all domains not in their local regions as 
foreign. For example, the UK administrator must mark all domains in 
the root region as foreign, and all domains in the US region as foreign. 


To mark all foreign domains as foreign, individually select all foreign 
domains on the Network Manager: Object List window and mark them 
as foreign on their respective Domain property sheets. 


1. Open the network definition for the local region, if it is not already 
open. 


2. On the Network Manager: Object List window, select Domain, then 
select a foreign domain in the Names column. Mark all foreign 
domains as foreign by selecting Foreign Item. 


‘The Network Manager displays a screen indicating it will update 
several different network objects, and a message asking “Do you 
want to proceed?” Select Yes. 


On the Region property sheet, you should not see any foreign 
domains listed in the Domains within Region list box. Also, you 
should not see any Names Servers that are not in the local region. 





Note: WORLD must also be marked as a foreign domain from 
the point of view of the UK and US regions. The WORLD 
domain is local to the ROOT region, even though it is not used 
in hierarchical configurations. 


PN SES SOS 


Define Foreign Regions 
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The root administrator and the delegated region administrators must 
define foreign regions and designate the domains as being in a specific 
foreign region. 


To create a foreign region: 


1. Select Local Region on the Network Manager: Object List window to 
display the Local Region property sheet. 
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The only domains that should display in the Domains within Region 
list are domains that are local to this region. The only Names 
Server(s) that should appear are those local to this region. 


2. To define a second region, select Foreign Region from the Create 


Menu in the Menu Bar. 
A default name appears which you can change if needed. 


3. Select the Domains page and choose from the available list all of the 
domains that are part of this region. 


4, Return to the General Page and define a name for this new region. 


Do this by selecting any of the domains that the region contains. The 
domain name you select will be appended onto the end of the 
region name; for example, US_REGION.UK.ACME.COM. 


For example, from the point of view of the UK administrator, a 
foreign region would be the root region or the US region. 


Periodically, while updating the network definition, a screen may 
display indicating that network objects will be deleted and updated. 
Changes made in the network definition are automatically 
propagated to other property sheets in the same network definition. 
For example, the foreign region property sheet called UK_REGION 
should display NameServer_2.UK.ACME.COM. 


Every region (other than ROOT) must define the root region as a foreign 
region in its network definition. The domains contained in the root 
region (ROOT, COM, ACME.COM, and WORLD) must be allocated as 
foreign domains. Upon defining the root region as a foreign region, 
Names Servers associated with the foreign region will be displayed in 
the Names Servers list box. 


An administrative region only needs to have a record of network objects 
in its own region, in any child regions directly below it, and the root 
region. Foreign regions that have a sibling relationship do not have to be 
defined as foreign regions. For example, the UK region does not have to 
define the US region as a foreign region because the US region’s 
domains are not children of the domains in the UK. In fact, the UK 
region only needs to have in its network definition addresses for any 
Names Servers in its own region, and any Names Servers in the root 
region. 

The root administrative region must have in its network definition the 
addresses of Names Servers in the root region, and Names Server 
addresses of any direct child regions only. 
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Remote Domains and Names Server Hints 


A domain that is not defined in the local region, the root region, or a 
direct child region may be listed in the Domains within Region list. 
Because the domain is not defined in the local region, root region, or 
any direct child regions, this domain is termed a remote domain or 
Names Server hint which tells the local region that this is a domain it 
will probably want to communicate with. If you define a remote 
domain, then the address of the Names Server handling that domain 
is “pre-cached”. This saves the user from the performance 
overhead of the first request for a network object address within the 
remote domain. 


When the Names Server starts up, it retrieves the Names Server 
addresses from that remote domain. For example, if the 
UK.ACME.COM domain is defined as a remote domain in the US 
region’s network definition, when the US region asks for the 
address of HR.UK.ACME.COM, the US region’s Names Servers will 
already have the address of the Names Servers in the UK region 
(which contains the UK.ACME.COM domain). 


If this domain was not defined as a remote domain in the US 
region’s network definition, when a client wants to connect to a 
network service in the UK.ACME.COM domain, the Names Server 
on their behalf will have to go first to the ROOT and ask the ROOT 
region’s Names Server for the address of the UK region’s Names 
Server. 


Defining Local and Foreign Domains in Network Manager 
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The network administrator must enter the information for domains and 
other related data within that administrative region by using Network 
Manager. Domains within each administrative region are known as 
local (or “domestic”) domains from that region’s point of view, while all 
other domains are foreign. 


Names are often retrieved across regions, resulting in data from one 
administrative region entering the Names Servers of another region. 
Clients never communicate directly with Names Servers in another 
region; rather, they communicate with a local Names Server and it 
forwards the request to the desired location. This process is described in 
more detail in the sections on resolving names to foreign domains. 


The following figure shows a client with a default domain of 
EUROPE.ACME. 
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Figure C - 3. Domestic and Foreign Domains 


From the point of view of the client in the AR2 region, the 
EUROPE.ACME and the ROW.ACME domains are domestic and the 
ACME and US.ACME domains are foreign. For example, the names 
ART.EUROPE.ACME or PASSPORTS.ROW.ACME are resolved directly 
using the client’s local Names Server. Requests for DEATH.US.ACME or 
TAXES.US.ACME, however, can only be answered by a Names Server in 
AR1, because they refer to the foreign domain US.ACME. The client 
would contact a Names Server in the AR2 region, which in turn would 
forward the request to a Names Server in ARI. 


When data is retrieved from a foreign region, the local Names Server 
returns the response to the client, and keeps the foreign data in its cache 
for a period of time. Foreign data that is retrieved and cached includes 
database addresses from foreign regions, and Names Server addresses 
that are not part of the system data. 


Because the data is stable (that is, itis not likely the data will be 
redefined frequently relative to the Time to Live value), caching data 
retrieved from another region is a low-cost, effective way to increase 
performance in the system. If another user requests the same name, the 
local Names Server can respond with the details from the cached data 
without forwarding the request. 


Data is not only cached in the Names Server supplying the client, it is 
stored in all Names Servers the name comes in contact with. Whenever 
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data is encountered in any way, subsequent requests will be faster if 
more Names Servers know the answer. 


Cached Foreign Data’s Time To Live (TTL) 


If all foreign data were stored indefinitely in other Names Servers, when 
changes occurred in a particular administrative region, this would 
invalidate many cached names in many Names Servers in the network. 


Because of this, foreign names are only stored in the cache for a 
predetermined length of time (default is one day) after which they are 
dropped. This is known as the cached data’s Time To Live (TTL) which 
literally counts down until the time expires and the name is dropped. 


The implications are that the foreign data in the cache is never older 
than the configured TTL. By default, each Names Server will query once 
per day for each foreign name in its cache, and it will query the Names 
Server in the region where the foreign name was defined. Once a 
Names Server gets a foreign name it is valid for the length of time in the 
configured TTL. After that, if a client requests the name, the Names 
Server will query the region where the data is considered local. 


The actual TTL value for a server is configured by using the Network 
Manager when the region is defined. All data in the region has the same 
TTL. You should choose the value based on the likelihood that the data 
will change, and the anticipation that it will be requested from other 
regions, Whenever a response is passed between regions, a TTL is set 
and begins counting down. 


Short TTLs propagate changes more quickly, but decrease overall 
performance because more queries must be resolved at the data source; 
that is, names must be resolved by retrieving them from the Names 
Server in the region where the data is considered local. 


In the event that source data in a particular region is changed by a 
network administrator, and the cached data is out of date for the 
remainder of the TTL, that name can be dropped (before the TTL 
expires) using the NAMESCTL command FLUSH_NAME. 


Authoritative vs. Non—Authoritative Responses 


Retrieved data is considered authoritative or non-authoritative. 


e authoritative (local data)—The response to a query is retrieved 
from the region where the data is considered local. 


e non-authoritative (foreign data)--The response is from the 
foreign data section of a Names Server cache. Whenever a Names 
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Server is supplying an answer that it cannot guarantee is correct, 
that answer is termed ”non-authoritative”. 


Many administrators get nervous at phrases like “not guaranteed”. 
Remember that non-authoritative data is simply a performance 
optimization to avoid having to retrieve data from its authoritative 
source every time. If the data in a particular Names Server is out of date 
(that is, the TTL has expired), the Names Server would look up the data 
in the region where the data is local. 


Pas Sa EE 
How Names are Resolved in Delegated Administrative Regions 


The term “delegated” refers to a network with multiple administrative 
regions. Many sites have a single administrative region. 


Name resolution among regions is a highly optimized process that 
minimizes communication between servers. In the absolute case, a 
region can find any other region by asking a Names Server in the root 
administrative region for the address of a Names Server in that region. 
Like foreign name caching, data such as local Names Server addresses 
and delegated Names Server addresses are also cached (with a TTL) to 
avoid having to request this data each time a query is made. Also, like 
foreign data, only the first query to a region requires looking up a 
Names Server address; all subsequent requests from the local Names 
Server use the cached system data. 


The following sections step through a simple and a complex case of 
name resolution across regions. Initially, the example assumes that no 
cross-region traffic has previously occurred, then subsequent requests 
are described. 


Resolving Names from Foreign Domains 


When a name is requested from outside the current administrative 
region, the following process occurs: 


1. The Names Server looks in its foreign data cache for the address of 
the Names Server it believes is most likely to be authoritative for 
that name. 


2. If the Names Server does not have the address of this Names Server, 
it queries the root administrative region for the addresses of Names 
Servers in that region. For the simple case, assume the root returns 
the address of the Names Server for that region (the authoritative 
Names Server). 
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3. The Names Server then forwards the request to the authoritative 
Names Server and the result is returned. 


4. . The Names Server stores that name and result in its foreign data 
cache, then returns the result to the client. 


In most cases this is a simple transaction. Consider the following 
example: 


1. The client in AR2 encounters the name DEATH.US.ACME and 
sends it to its preferred Names Server in the AR2 region. 


2. The Names Server in AR2 determines that the domain is foreign and 
looks in its system data cache for the Names Server address of the 
foreign domain in AR1. 


3. In this case, the foreign region is the root region (AR1), thus the 
request is forwarded to a Names Server in ARI and the result is 
returned to the Names Server in AR2. 


4, The local Names Server in AR2 stores the name in its foreign data 
cache and returns the name to the client. 


No foreign system data is cached since the root administrative 
region’s Names Servers are already part of every delegated region’s 
defined system data. 


Resolving Multi-Level Names Across Administrative Regions 
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Finding an authoritative server in a very large distributed 
administrative hierarchy can require iteration. If, for example, a Names 
Server asked for the address of a Names Server servicing a grandchild 
region of the root (two levels down), the root may only know the 
addresses of one of its direct children, which in turn can supply its 
children’s addresses. In other words, the root forwards the request to its 
child region, which would forward the request to its child region for the 
answer. 


Figure C ~ 4 shows this process and the sequence of events assuming 
that no data has been previously cached. 


1. The client sends request to preferred Names Server in its local 
region (DR1). 


2, The preferred Names Server in DR1 issues request for the Names 
Servers authoritative for the destination server (in region DR2.1). 
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Figure C- 4 Network Messages in a Multi-Level Foreign Name Resolution 


3. 


The root Names Server does not have the answer (because root only 
knows about its direct child regions), but forwards the request to a 
Names Server in region DR2. 


The receiving server in DR2 forwards the request to a Names Server 
in region DR2.1. 


The name is retrieved from its authoritative Names Server in DR2.1. 


The names Server in region DR2 caches the answer and returns it to 
the root. 


The root caches the answer and returns it to the preferred Names 
Server in region DR1. 


The preferred Names Server caches the answer and returns it to the 
client. 


The client establishes a connection to the destination server. 


For the duration of the TTL, subsequent requests for the same name to 
the same Names Server do not require step 9. 


Also for the duration of the TTL, any subsequent requests in DR1 for 
names in the DR2.1 region are resolved by communicating directly with 
its servers. 
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More Examples of How Names are Resolved Across Administrative Regions 


Additional examples will make this process clearer. Following are two 
examples: one which resolves a database service name across regions, 
and the second which resolves both a database link and a database 
service name across regions. 


Note: These examples extend the naming model enough to 
explain detailed cross—region name resolution. If you are not 
using more than one level of delegation, it is not important that 
you read the sections on multi-level delegation. In practice, five 
level domain naming models, and three level administrative 
region delegation are rare. 


Figure C —5 shows a client in the administrative region AR4.1 (default 
domain JP ROW.ACME) connecting to the database server 
BLUE.GA.US.ACME, which performs a distributed query to the 
database server JAY.LONDON.UK.EUROPE.ACME. 
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Figure C- 5 Name Resolution in a Complex Administrative Hierarchy 
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When the client issues the request, the Names Server in the AR4.1 
region looks at the domain name (GA.US.ACME), recognizes it as 
foreign (not local), and issues a request to a root Names Server for 
Names Server addresses in the region with GA.US.ACME. 


A root Names Server forwards the request to ARI. 


The name is resolved and returned to a Names Server in the root 
region. 


The Names Server in the root region returns the request to AR4.1. 
The Names Server in region AR4.1 returns the name to the client. 


The client establishes a SQL*Net connection to the database server 
BLUE.GA.US.ACME. 


Note that the AR4 region is not involved. Resolution goes directly from 
the requesting region to the root, then to AR1 directly. Subsequent 
requests within AR4.1 for the same name will be resolved from the 
Names Server cache in AR4.1 until the Names Server TTL expires. 

(Refer to the “Cached Foreign Data Time to Live (TTL)” section earlier in 
this appendix) Subsequent requests for other names in the AR1 region 
by clients in AR4.1 will not contact the root. 
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The same process is followed when a user on the database 
BLUE.GA.US.ACME in AR1 uses the global database link 
JAY.LONDON.UK.EUROPE.ACME. 


1. The database BLUE.GA.US.ACME contacts its preferred Names 
Server (in region AR1) with a request to resolve 
JAY.LONDON.UK.EUROPE.ACME. 


2. The preferred Names Server in ARI contacts the root region for the 
addresses of the servers in region AR3.1. 


3. Because the root doesn’t have them, it forwards the request to the 
AR3 region of the Name Server. 


4, The Names Server in region AR3 contacts a Names Server in region 
AR3.1 with the name to be resolved. 


5. The Names Server in region AR3.1 resolves the name and returns it 
to the server in region AR3. 


6. The Names Server in region AR3 stores the name in its cache and 
returns the name to the root. 


7. The root region’s Names Server caches the name and returns it to 
ARI. 


8. The Names Server in AR1 stores the name in its cache and returns it 
to the server BLUE.GA.US.ACME. j 


9. The server BLUE.GA.US.ACME establishes a connection to the 
server JAY,.LONDON.UK.EUROPE.ACME. The global database link 
is complete. 


Subsequent requests for the JAY.LONDON.UK.EUROPE.ACME global 
database link will be identical to the process in steps 1 and 8. As a local 
name, it is already optimized. Subsequent requests for the name 
JAY.LONDON.UK.EUROPE.ACME will be resolved in the foreign data 
cache. Subsequent requests for other names in the AR3 or AR3.1 regions 
will be made directly to those regions—the root region is not required. 


Optimizing for Repeated Queries 
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The Oracle Names system is specifically optimized to ensure that the 
costs incurred in examples like the ones above are minimized. After a 
small number of inter-region queries, a Names Server will usually know 
all of the addresses of the Names Servers in the regions it will contact 
that day. It is very infrequent that the number of messages shown in the 
previous example is required. 


Table C —3 is a summary of the Names Servers involved in the 
client/server connection between the client in region AR4.1 and the 
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server BLUE.GA.US.ACME in region AR1. It includes the Names 
Servers involved from each region, the information they learned 
(cached), and what they already knew (from the network definition 


database). 





Names Server in: 


Learned 


Already Knew 














region AR4.1 Service name data: Addresses of Names 
BLUE.GA.US.ACME Servers in region ROOT 
Addresses of Names 
Servers in region ARI 

region ARI Nothing Addresses of Names 


Servers in region ROOT 
Service name data: 





BLUE.GA.US.ACME 





BLUE.GA.US.ACME 





Table C-3 Foreign Data Storage in Name Resolution between the Client and 


Similarly, resolution of the global database link name 
AY.LONDON.UK.EUROPE.ACME from the Names Server in the AR1 


region is performed through the ROOT region, and down the hierarchy 
with the following foreign data stored, as shown in Table C - 4. 








region AR3.1 


Addresses of Names 
Servers in region AR3.1 
Addresses of Names 
Servers in region AR3 


Nothing 


Names Server in: | Learned Already Knew 

region ARI Service name data: Addresses of Names 
JAY.LONDON.UK. Servers in region ROOT 
EUROPE.ACME 


Addresses of Names 
Servers in region ROOT 


Service name data: 
JAY LONDON.UK.EU- 
ROPE.ACME 





region AR3 








Service name data: 
JAY.LONDON.UK.EU- 
ROPE.ACME 





Addresses of Names 
Servers in region ROOT 


Addresses of Names 
Servers in region AR3.1 








Table C -4 Foreign Data Storage in Name Resolution between. 
BLUE.GA.US.ACME and JAY.LONDON,UK.EUROPE.ACME 


Advanced Topics C-19 





Defining Objects in Foreign Domains 






In a network with distributed administration, the need to define aliases 
for network objects in foreign domains will occasionally arise. This need 
is most common with database links, as any user can create database 
links in any database where the user has an account and adequate 
database privileges. For this reason, the network administrator may 
need to define an alias for a global database in that foreign domain in 
Network Manager. 


For instance, assume the following example is extended to include a 
second global database link in the Names Server in the AR1 region 
called HR, as shown in Figure C - 6. 
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Figure C- 6 Alias for a Database Defined in a Foreign Domain 


If the database user happens to be in Japan, the name HR.GA.US.ACME 
can be added through the administrator in region AR4.1 by: 


e defining the foreign domains US.ACME and GA.US.ACME 


+ creating the alias HR for the database BLUE within the foreign 
domain GA.US.ACME 


Foreign domain definitions only require the name; all other system data 
is looked up by Oracle Names. 
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Optimizing Performance with Foreign Domain Lookup 


To optimize Names Server performance, the network administrator 
defines all foreign domains in Network Manager. When you start a 
Names Server, it collects all foreign domain references defined in 
Network Manager for its administrative region, and requests the 
addresses of the Names Servers for their regions using the process 
described earlier in this chapter. The results are stored in the cache in 
anticipation of names in the foreign domain being requested. Any 
requests by clients for data in that administrative region can then 
forward name requests to the regions containing the foreign domains 
directly, without using the root domain to find them. 


This initial operation is a series of system queries to store the foreign 
server addresses in advance of a foreign domain name request. The 
result is a performance optimization when clients request names from 
that domain. 


Using the example in following figure: 


> All Names Servers in region AR4.1, at startup, request the 
addresses of the Names Servers in the AR1 region from the root 
region. (This is because the GA.US.ACME domain is defined as a 
foreign domain in the network definition in the AR4.1 region.) 


+ A root région server returns the Names Server addresses and they 
are stored in the system data cache in the AR4.1 region. 


When the client requests the database BLUE.GA.US.ACME in the ARI 
region, the request is forwarded from the Names Server in region AR4.1 
directly to a Names Server in the AR1 region. 


Foreign Data and Names Servers 


All Names Servers in an administrative region share the same local (or 
“domestic’) data as well as the addresses of Names Servers in the root 
region. All Names Servers in a particular region start with the same 
pre-defined data, for example, local database names, root region’s 
Name Server addresses, and Names Server addresses in foreign regions. 
Any other information learned through answering queries will stay in 
an individual Names Server cache, but other Names Servers in the same 
region may not have the exact same information at all times. After 
running for a while, each Name server cache in a region will be unique. 


Within a region then, each Names Server may behave differently when 
resolving a foreign name, depending on its previous experiences and the 
state of its cache. In all but the rarest occasions, the query results will 
always be the same. 
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Network Support 


Ina multi-community TNS network, choosing a multi-protocol node as 
a Names Server minimizes the number of nodes that need to be installed 
for redundancy. There is certainly no requirement that the Names Server 
run ona multiple protocol node; it is a matter of minimizing 
administrative overhead for complete TNS network naming service 
coverage. 
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Glossary 


address A unique network location used to 
identify a network object such as a database 
service, client, Interchange, or Names 
Server, TNS addresses have a specific 
format. Addresses must be unique. See 
TNS address and well known address. 

administrative region An organizational 
region is an organizational entity for 
administering SQL*Net network 
components. Each administrative region 
includes: 


e one or more domains 
* one or more Oracle Names Servers 
o TNS network definition 
~ one or more communities 
— zero or more Interchanges 
e network object definitions 


alias An alternate name for an existing 
network object. Once created, alias 
resolution is the same as resolving the initial 
object. For example, if an alias named 
PAYCHECK.WORLD is created for the 
database service PAYROLL.WORLD, the 
following commands are equivalent: 


sqlplus scott/tiger@PAYCHECK.WORLD 
sqlplus scott/tiger@PAYROLL.WORLD 





authoritative response A Names Server 
response from the source, or owner, of the 
data requested. The source is any Names 
Server in the same administrative region as 
the requested name. 


backbone data See network data. 


cache The in-memory database within a 
Names Server where all data is stored. The 
cache has three basic sections: the system 
cache, the authoritative data cache, and the 
non-authoritative data cache, which 
represent different types of data with 
different refresh frequencies. 


central administration A SQL*Net network 
in which all data is administered in one 
administrative region. 


client profile The properties of a client, often 
shared by many clients. Includes the 
protocols used, preferred Interchanges, 
preferred Names Servers. Also called 
“client type”. 

community A group of network clients and 
servers using TNS-based software that can 
communicate using the same 
industry-standard protocol. 
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configuration files Files that are used to 
identify and characterize the components of 
a network. Configuration is largely a 
process of naming network components and 
identifying relationships among those 
components. 


connect descriptor A specially formatted 
description of the destination for a network 
connection. Connect descriptors are 
constructed using a set of keywords and 
values. They are mapped to service names to 
provide more convenient reference. 


database service name See service name. 


database link A network object stored in the 
local database or in the network definition 
that identifies a remote database, a 
communication path to that database, and 
optionally, a username and password. Once 
defined, the database link is used to access 
the remote database. Also called DB link. 


A public or private database link from one 
database to another is created on the local 
database by a DBA or user. 


A global database link is created 
automatically from each database to every 
other database in a network with Oracle 
Names. Global database links are stored in 
the network definition. 


default domain The domain within which 
most client requests take place. It could be 
the domain where the client resides, or it 
could be a domain from which the client 
requests network services often. A client 
configuration parameter determines what 
domain should be appended to unqualified 
network name requests. A name request is 
unqualified if it does not have a ”.” 
character within it. 
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delegated administration A SQL*Net 
network where network management is 
delegated to one or more administrative 
regions below the root administrative 
region. Each region is administered through 
an installation of the Network Manager. 
Also referred to as “distributed 
administration” and “decentralized 
administration”. 


delegated administrative region A region 
that is hierarchically below the root 
administrative region. Any region other 
than the root administrative region. 


decentralized administration See delegated 
administration. 


distributed administration See delegated 
administration. 


domain A grouping of network objects, such 
as databases, that simplifies the naming of 
network services. Within a domain, all the 
names must be unique. 


domestic domains The set of domains that 
are managed within a given administrative 
region. Domains are only domestic relative 
to a region; they are never domestic in any 
absolute sense. Also referred to as local 
domains. 


dynamic discovery The process whereby 
well-known naming service addresses are 
hardcoded into both the Oracle Names 
Server and its clients. Oracle Names Servers 
are available at these well known addresses, 
so that clients do not need to be told, by way 
of configuration files, where to find the 
server. All listeners and databases register 
themselves automatically with an Oracle 
Names Server at a specific well-known 
name and address. 


flat naming model An Oracle Names 


infrastructure in which there is only one 
domain. All names must be unique within 
that domain. 


foreign domains The set of domains not 


managed within a given administrative 
region. Domains are only foreign relative to 
a region; they are not foreign in any absolute 
sense. A network administrator typically 
defines foreign domains relative to a 
particular region in the Network Manager to 
optimize Names Server caching 
performance. 


global database link A database link created 


automatically by the Network Manager for 
use with Oracle Names that links each 
database in a network to all other databases. 
This enables any user of any database in the 
network to specify a global object name ina 
SQL statement or object definition. (The 
global object name for the DBlink must be 
the same as the database service name.) 


global database name A unique name that 


identifies a database in a network. It 
consists of a database name and its network 
domain name. For example, 
HR.US.ORACLE.COM is comprised of a 
database name component HR and a 
network domain component 
US.ORACLE.COM. 


hierarchical naming model An Oracle Names 


infrastructure in which names are divided 
into multiple hierarchically-related 
domains. You can use the hierarchical 
naming model with either central or 
delegated administration. 


logging A feature in which client or server 


errors, service activity, and statistics are 
written to a log file. See also tracing. 


MuitiProtocol Interchange An Oracle 
network product that allows applications in 
TNS networks to communicate across 
different protocols. For example, a TCP/IP 
client could connect through an Interchange 
to an Oracle7 server running only DECnet. 


naming model The set and structure of 
domains within which names can be 
allocated. 


Ina flat naming model, there is a single 
domain. 


Ina hierarchical naming model, the highest 
level is the root domain, and all other 
domains are hierarchically related. 


network administrator The person who 
performs network management tasks such 
as installing, configuring, and testing 
network components. The administrator 
typically maintains the configuration files, 
TNS connect descriptors and service names, 
aliases, and public and global database 
links. 


network data Also called backbone data. 
Includes all communities and MultiProtocol 
Interchanges in the entire network, and all 
Names Servers in the root administrative 
region. Because backbone data is common 
to all administrative regions, all delegated 
administrative regions must have an 
identical copy of the backbone data. 
Backbone data is entered identically into 
each installation of the Network Manager. 
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network definition The network 
configuration created by the Network 
Manager fully describes one region. When 
you enter and save information in the 
Network Manager, it creates a network 
definition in an operating system file or a 
database. It generates configuration files 
from the network definition, and uses it as a 
data source for Oracle Names. 


Network Manager The graphical tool for 
configuring and maintaining services in a 
SQL*Net network, including SQL*Net, 
MultiProtocol Interchange, and Oracle 
Names. Each administrative region runs a 
separate copy of the Oracle Network 
Manager. 

network objects The types of network names 
stored in an Oracle Names Server. These 
includes database service names, global 
database links, and aliases. 


non-authoritative data Ifa Names Server 
returns a name from its foreign cache 
without asking the authoritative Names 
Server, this name is termed 
“non-authoritative”. The name is termed 
“authoritative” if the data source was asked. 

ORACLE_HOME An alternate name for the 
top directory in the Oracle directory 
hierarchy on some directory—based 
operating systems. 

Oracle Names A name resolution system for 
Oracle? and SQL*Net networks. Oracle 
Names includes: 








e one or more Oracle Names Servers 


e one or more Oracle Network Manager tool 
installations 


Oracle Names infrastructure A set of initial 
decisions and policies that govern how 
names are allocated, and how Oracle Names 
operates. The infrastructure defines how 
users and administrators interact with the 
Oracle Names system. 
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Oracle System Identifier (SID) A unique 
name for an Oracle database instance. To 
switch between Oracle databases, users 
must specify the desired SID. The SID is 
included in the CONNECT DATA parts of 
the connect descriptors in a 
TNSNAMES.ORA file, and in the definition 
of the network listener in the 
LISTENER.ORA file. 


Oracle Names Server (Names Server) The 
name resolution software for efficiently 
answering name requests. 


password A string (word or phrase) used for 
data security and known only to its owner. 
Passwords are entered in conjunction with 
an operating system login ID, Oracle 
username, or account name, in order to 
connect to an operating system or software 
application (such as the Oracle database). 
Whereas the username or ID is public, the 
secret password ensures that only the owner 
of the username can use that name, or access 
that data. 


preferred Names Server The Names Server(s) 
preferred by a client for names resolution; 
usually the Names Server that is physically 
closest to the client, or available over the 
least expensive network link. 

private database link A DBlink created by 
one user for his or her exclusive use. Also 
see public database link, database link, or global 
database link. 

public database link A database link created 
by a DBA ona local database which is 
accessible to all users on that database. Also 
see database link and global database link. 


toot domain The highest level domain in a 
hierarchical naming model. 

root administrative region The highest level 
administrative region in a distributed 
installation. The root administrative region 
contains the root domain. 


service name A name for a TNS service 
that is easy to use and remember. End users 
need only know the appropriate service 
name to make a TNS connection. Each 
connect descriptor is assigned a service 
name in the network definition. The service 
name for a database link must be the same 
as the global database name. 


service replication A process that fully 
replicates a directory system on the 
network. New services need to register with 
only one Names Server. The service 
replication process automatically distributes 
the new registration to to all other active 
Names Servers on the network. 


SQL*Net An Oracle product that works with 
the Oracle Server and enables two or more 
computers that run the Oracle RDBMS or 
Oracle tools such as SQL*Forms to exchange 
data through a network. SQL*Net sw pports 
distributed processing and distributed 
database capability. SQL*Net runs over and 
interconnects many communications 
protocols. 


system or topology data Data used by the 
Names Server to control regular functioning 
or communicate with other Names Servers. 
Includes communities, Interchanges, root 
region’s Names Servers, and any delegated 
regions’ Names Servers. 


TNS A foundation technology, built into 
SQL*Net V2.x, the MultiProtocol 
Interchange, and Oracle Names, that works 
with any standard network transport 
protocol. Also called Transparent Network 
Substrate. 





TNS address An address of a client or 
network service on a TNS community, 
which identifies the community to which it 
belongs, the protocol used by that 
community, and some protocol-specific 
values. One TNS client or network service 
may have multiple TNS addresses if it 
resides in multiple communities. 


TNS communities A group of Oracle 
applications running on computers that 
communicate using the same network 
protocol. 


TNS network One or multiple TNS 
communities connected by MultiProtocol 
Interchanges. All members of a TNS 
network can communicate regardless of the 
protocol they run. 


tracing A facility that writes detailed 
information about an operation to an output 
file. The trace facility produces a detailed 
sequence of statements that describe the 
events of an operation as they are executed. 
Administrators use the trace facility for 
diagnosing an abnormal condition; it is not 
normally turned on. 


username The name by which a user is 
known to the Oracle Server and to other 
users. Every username is associated with a 
password, and both must be entered to 
connect to an Oracle database. 


well-known address In Dynamic Discovery 
networks, these are addresses for one or 
more Names Servers which are hardcoded 
into both the Oracle Names Server and its 
clients. Oracle Names Servers then become 
available at these well known addresses, so 
that clients do not need to be told, by way of 
configuration files, where to find the server. 
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AT eae parameter, using with QUERY, 
average response time, A — 19 
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central administration, 3 — 10 
one Network Manager, 3 - 10 
centralized administrative regions, examples, 
3-10 
CFGnnnnn.ORA file, 2-8 
changes 
client profile, C -2 
in administrative regions, 3 ~ 11 
network data, 3 - 16 
changing database names, 7-4 
changing objects, 1-4 
checkpoint configuration, 2-8 
checkpoint file, update interval, 6 -4 
checkpoint files, 2- 7 
Choices for Dynamic Discovery, in a network, 


choosing a naming model, 4-2 
client 
default domain, 7 — 6 
definition, 3-17 
network object request, 7 — 6 
parameters, 6 - 13 
client communication, C - 10 
client configuration, 7 — 6 
client file, out-of-date, 7-10 
client profile 

default, C- 4 

configuration files, C- 4 
client profile, editing, changing preferred 

Names Server, 6 - 11 

client profiles 

changes, C-2 

defining, 6 — 10 

limiting the number, C - 4 

number required, C - 4 

sample, C -2 

sharing, 6-11,C-2,C-4 
command line mode, NAMESCTL, A -2 
command summary, NAMESCTL, A -5 
command types, NAMESCTL, A ~2 
comments, in batch mode, A - 2 
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communities 
definition of, 3-17 
in network, 3-4 
in root administrative region, 3-15 
Names Servers, 4- 6 
protocols on node, 3-4 
community based model, of network, 3 -4 
compatibility, between versions, 1-4 
components, Names Server, 2- 6,3-3 
computer platforms, Oracle Names, 4-7 
configurable parameter settings, current set- 
tings, 2-8 
configuration 
administrative regions and domains, 3 - 17 
Names Server, 3- 17,7 -7 
configuration error, 7 — 10 
configuration files 
sharing, C -4 
client profile, C - 4 
distributing, 7- 1 
for non-default values, in the DDO, 2-3 
configuration parameters 
client, 6- 11 
client, 6-13 
Names Server, 6 — 4 
Oracle Names, 6 - 4 
Oracle Names control utility, 6 - 17 
scope, 6-12 
configuration process, steps in, 6 — 2 to 6-4 
configuration settings, overriding, A-3 
configured log file, statistics, A - 12 
confirmation, setting requirement, 6 - 17 
confirmation mode, changing, A-5 
connection qualifiers, using, multiple database 
links, 6 - 20 
connection time, through an Interchange, 4-7 
connections, maximum Names Server, 6 - 7 
control utility, Oracle Names, A-1 
control utility environment, changing proper- 
ties, A-3 
CPU requirements, for Names Server, 4 ~ 8 
crash, Names Server, 2 - 8 





create new network, using Dynamic Discovery 
Option, 5-4 to5-6 
cross~region name resolution, C - 13 
current Names Server, A — 39, A ~ 40 
current tracing level, A -36 
determing, A - 43 
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data changes 
managing, 3 ~ 16 
requesting, 7-2 
TTL value, C - 12 
checking for, A ~ 18 
large volume, A -9 
Names Server, 7 ~ 4 
data definitions, for delegated regions, 3 - 16 
data volume, 3 -11 
database link 
in distributed database, 3 - 18 
use by Names Server, 7-7 
database link security, 7-7 
database links, 7 - 5 
creating, C - 20 
resolving, 7 -7 
defining in Network Manager, 6 - 19 
global, 1-5 
database service name, definition, 1 - 5 
database service names, 7-5 
database services, defining in Network Manag- 
er, 3-17 
databases, deleting, C -7 
dead connection detection, in SQLNET.ORA 
file, 5 ~- 15 
decentralizing administration, 3 ~ 11 
to solve duplicate name requests, 4 ~ 3 
decisions, when planning for Oracle Names, 4 
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dedicated Names Server, in SQLNET.ORA file, 
5-15 
default client profile, C -4 
default domain, 3-8 
displaying, 7-8 
defining for client, 6-11 


determining, A -33 
Default domains, in Dynamic Discovery net- 
works, 2-5to2-7 
default domains, illustrated, 3-9 
default settings, overriding, A -3 
DEFAULT_DOMAIN, initial setting, A ~ 22 
defining client profiles, 6 — 10 
delegated administration, 4 —5 
delegated administrative installations, estab- 
lishing, 4-5 
delegated administrative region, requirements 
for establishing, 4 - 6 
delegated administrative regions 
creating foreign objects, C - 20 
illustrated, 3-12 
requirements, 3-16 
child regions, 3 - 16 
delegating administration, 3 ~ 11 
delegating administrative regions, rules, 3 - 13 
delegating authority, from central region, C-5 
deleting database names, 7 - 4 
difference between, communities and domains, 
3~9 
directory 
log file, 6-5 
NAMESCTL trace file, 6 ~ 18 
trace files, 6-8 
disable out of band breaks, in SQLNET.ORA. 
file, 5-15 
distributed administration, RELOAD, A - 18 
distributed administrative installations, non- 
authoritative data, 7-4 
aca i configurations, system queries, A 
-41 
distributed databases, database links, 7 - 7 
distributed global name resolution, C - 13 
distributed installation, data changes, 3 ~ 16 
distributed operation, NAMESCTL program, 
A-3 





distributing configuration files, 7 ~1 

DNS internet model, adapting names for, 4-3 
domain, naming considerations, 3 - 8 

domain based model, example, 3~5 to 3-7 
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domain hierarchy, 3 - 13 
Domain Name Service, global naming conven- 
tions, 4-2 
Domains, change in treatment, for Dynamic 
Discovery networks, 2-4 
domains 
configuration, 3 - 17 
in administrative regions, 3 - 13 
naming levels, 3 - 13 
subdividing, 4-3 
definition, 3 - 7 
types, C- 10 
domains and communities, differences, 3-9 
duplicate name requests, avoiding, 4-3 
Dynamic Discovery, in a network, 2 — 3 to 2- 5 
Dynamic Discovery, 1 - 1 
choices, 1-3 to 1-5 
components of, 2-6 to 2-8 
create new network, 5-4 to5-6 
in your network, 2-3 to2 -5 
non-default parameters, 5 - 13 
upgrading to, 5- 1 to 5-17 
Dynamic Discovery Option, 6 -2 
limitations, 2-1 
rules for upgrades, 5-3 to 5-5 
Dynamic Discovery registration, 2- 2 
Dynamic service registration, 2 —2 
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environments supported, Oracle Names, 4—7 
errors, name resolution, A -9 
EXIT command, NAMESCTL program, A - 8 
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failures 
Oracle Names, 7 ~5 
tracing, A — 25 

files, checkpoint, 2-8 

flat naming model, 3 - 6 
default domain, 6-11 
growth considerations, 4-3 
illustrated, 3 -7 
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FLUSH command, 7-4 

using, 7-5 

using on individual objects, 7 — 6 

effect, 7-5 

NAMESCTL program, A -9 
FLUSH_NAME command, C- 12 

NAMESCTL program, A -10 
flushing multiple Names Servers, 7- 5 
foreign data 

removing, 7-5 

flushing, A -9 
foreign data cache, C - 11 

non-authoritative response, C — 12 

time limit, C - 12 

when out-of-date, C - 12 
foreign data cache checkpoint, 2 — 8 
foreign data caching, affects, C -18 
foreign database link, example, C - 20 
foreign domains 

definition, C — 10 

marking, C -8 
foreign name resolution 

examples, C - 16 

simple case, C - 13 
foreign names, locating directly, C- 21 
foreign names data, invalid, C ~ 12 
foreign names retrieval, C - 12 
foreign objects, definition, C - 20 
foreign regions, defining, C ~8 
foreign server addresses, storing, C - 21 
forwarder, definition of, 2 -7,3-3 
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global database links 
defining in Network Manager, 6 — 19 
definition, 1-5 
global database name, 1-5 
global database names, restrictions, 6 -21 
global links, specifying username and pass- 
word, 6-20 
global name requests, 6-11 


global name resolution 
client/server, 3—17 
client/server steps, 3 - 18 
database link steps, 3 ~ 20 
database links, 3 - 19 
distributed, C-13 


global naming standards, 4 ~ 2 
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handling data change requests, on a Names 
Server, 7-2 
HELP command, NAMESCTL program, A - 
11 
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illustrated, 3-7 ‘ 
illustrated, 3 ~8 


how networks work, with the DDO, 2-3 
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inaccurate data, using the FLUSH command, 7 


informational commands, NAMESCTL, A -2 
infrastructure, Oracle Names, 3 -1 
installation policies, recommended, 4-5 
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Interchanges 

part of network, 3-15 

using preferred, C - 4 
internet, global naming conventions, 4 — 2 
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we administrative regions, examples, 3 - 


invalid data, in Names Server, 7 ~9 
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key components, Oracle Names, 2 - 6, 3-2 
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layout, network, 3-4 
levels of tracing, A - 25 


load balancing, C-4 
using multiple Names Servers, 4-6 

local region, 3 - 12 

LOG_STATS command, NAMESCTL program, 
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logging and tracing parameters, in SQLNET.O- 
RA file, 5-15 

logging frequency, changing, A ~ 24 

logging statistics, Names Server, A ~ 12 
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mail account, using for Oracle Names, 7 - 2 
maintaining Names Servers, 7 ~ 1,7 -4 
maintenance considerations, Names Servers, 4 
-8 
memory required, 1-7 
merging naming models, example, 4-4 
Migration rules, B - 4 
modes of operation, NAMESCTL, A - 2 
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tions, 4-7 
multi-protocol node, advantages, 4-8, C ~ 22 
multiple administrative regions, 3-12, 4-4 
name resolution, C - 13 
multiple communities, Names Servers, 4-6 
multiple database links, defining, 6 ~ 20 
multiple domains, 3 - 8,3 -9 
multiple Names Servers 
flushing, 7 - 5 
system performance, 4-6 
multiple servers 
accessing, 6 ~- 11 
testing, 7-4 
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switching between, A — 29 
multiple user accounts, security, 7 — 8 
MultiProtocol Interchanges 

definition of, 3-17 

in root administrative regions, 3 - 15 
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name data requests, installation policy, 4-5 
name requirements, region, 3 — 10 
name resolution 
complex case, C - 16 
cross-region, C - 13 
distributed environment, 3- 19 
distributed global, C -13 
multi-level foreign, C- 14 
process, 3-18 
results, C - 21 
sample foreign, C- 16 
single administrative region, 3 - 17 
name resolution errors, A-9 
name resolution process, client/server exam- 
ple, 3-18 
name retrieval, foreign, C - 11 
names cache, definition, 2-7,3-3 
Names Control Utility, affecting through 
Oracle Network Manager, 6 - 2 
names requirements, using flat model, 3-7 
names resolution, repeated queries, C-18 
Names Server 
availability, A - 27 
available data, C - 21 
changing parameter settings, A — 1 
changing properties, A -3 
checking availability, 7 - 10 
checkpoint files, 2 ~ 8 
components, 2 — 6 
without the DDO, 3 -3 
components in DDO, 5-2 to 5- 4, B -1 to B 
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current, A-39, A-40 
determining search path, 7 - 10 
ensuring reliability, 3- 10 
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entering password, 4 -9 
hints, C-9 
in administrative regions, 3-11 
log file, 4-9 
log file name, 6 —6 
logging statistics, A - 12 
maintenance, 7-4 
management, A — 1 
maximum connections, 6-7 
name, 6-8 
network support, 4-8 
parameters, 6-4 
preferences, C -4 
preferred, 6- 11 
proximity of data access, 4 - 7 
repercussions of unavailability, 4-7 
requirements for communities, 4-7 
resetting statistics, A — 20 
role of, 3-18 
security, A — 46, A — 48 
selection criteria, 4-8 
shutting down, 7 -2 
starting, 5-5, 5—8,5- 11,7-2 
startup, 2-8,5-6, A-46, A -48 
startup example, A — 48 
statistics, A -- 50 
stopping, A - 45, A - 52 
trace file, 4-9,6-8 
unavailability, 4 - 6 
using preferred, C - 4 
well-known, 1 -2 
where installed, 4-7 
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illustrated, 2-7 
without the DDO, illustrated, 3-4 
Names Server configuration, 7 -7 
Names Server data 
installation policy, 4-5 
testing, A~- 15 
Names Server failure, diagnosing, 7-8 
Names Server failures 
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Names Server not found, 7 — 10 
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Names Server functions, without DDO, 3 ~ 2 to 
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Names Server nodes, selecting, 4-8 
Names Server requirements, 1 -6 
Names Servers 
changes in root, 3 — 16 
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in delegated regions, 3-15 
in root adminstrative region, 3-15 
in root region, 3 - 16 
maintaining, 7 — 1 
number in administrative regions, 3 — 10 
pointing to, 7-9 
reloading all, 7-4 
setting preferred Names Servers, 5 - 15 
testing, 7 ~4 
Names Servers, preferred, in SQLNET.ORA, 6 
-11 
names.cache_checkpoint_file, Names Server 
parameter, 6 ~ 4 
names.cache_checkpoint_interval, Names 
Server parameter, 6 - 4 
names.default_domain, client parameter, 6 - 13 
NAMES.DEFAULT_DOMAIN parameter, 7 - 6 
names.log_directory, names Server parameter, 
6-5 
names.log_file, Names Server parameter, 6 ~ 6 
names.log_stats_interval, Names Server pa- 
rameter, 6-6 
names.max_open_connections, Names Server 
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NAMES.ORA file, A - 4 
missing, 7 - 11 
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14,6-15 
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9 


address, 7 - 10 
client, 7 ~6 
on Names Server, 7 ~7 
names.reset_stats_interval, Names Server pa- 
rameter, 6 ~ 7 
names.server_name, Names Server parameter, 
6-8 
names.trace_directory, Names Server parame- 
ter,6-8 


names.trace_file, Names Server parameter, 6 ~ 


names.trace_level, Names Server parameter, 6 
names.trace_unique, Names Server parameter, 
6-9 
NAMESCTL 
SHOW TRACE_LEVEL command, A - 43 
SHUTDOWN command, A - 45 
START command, A - 46 
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STATUS command, A - 50 
STOP command, A - 52, A - 53, A - 55 
basic operations, 7-2 
EXIT command, A -8 
FLUSH command, A -9 
FLUSH _NAME command, A - 10 
or administering Oracle Names, 1 - 6 
HELP command, A - 11 
LOG_STATS command, A ~ 12 
modes of operation, A ~ 2 
overview, A-2 
parameter options, A -3 
PING command, A ~ 13 
QUERY command, A - 14 
QUIT command, A - 16 
RELOAD command, A - 17, A-18 
REPEAT command, A - 19 
RESET_STATS command, A - 20 
RESTART command, A - 21 
security, A — 4 
SET DEFAULT_DOMAIN command, A ~ 22 
SET LOG_STATS_INTERVAL command, A - 
23, A ~ 24 
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mand, A - 25 
SET PASSWORD command, A - 26 
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27 

SET RESET_STATS_INTERVAL command, A 
-28 

SET SERVER command, A - 29 
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SHOW FORWARDING_AVAILABLE com- 
mand, A -32 

SHOW LOG_FILE_NAME command, A -34 

SHOW LOG_STATS_INTERVAL command, 
A-35 

SHOW NAMESCTL_TRACE_LEVEL com- 
mand, A -36 

SHOW REQUESTS ENABLED command, A 
-37 

SHOW RESET_STATS_INTERVAL com- 
mand, A -38 

SHOW SERVER command, A - 39 

SHOW STATUS command, A ~ 40 

SHOW SYSTEM_QUERIES command, A - 


41 
SHOW TRACE_FILE_NAME command, A - 
42 


SHOW VERSION command, A - 44, A -56 
NAMESCTL commands, confirmation mode, 
A-5 
NAMESCTL parameters, adding to 
SQLNET.ORA file, 6 - 4, 6 - 12 
NAMESCTL program 
using the FLUSH command, 7 - 5 
using the PING command, 7 ~ 4 
using the QUERY command, 7-5 
using the SHUTDOWN command, 7-2 
using the STARTUP command, 5 -- 5, 5 - 8, 5 
-11,7-2 
command summary, A - 5 
scope, A -3 
SET FORWARDING AVAILABLE, A ~ 23 
NAMESCTL reference, A -1 
NAMESCTL utility 
specifying configuration parameters, 6 — 12 
tracing, 6-17 
NAMESCTL utility tasks, 7 - 2 
namesctl.noconfirm, client parameter, 6 — 17 
NAMESCTL.PASSWORD, in SQLNET.ORA, A 
-4 
namesctl.server_password, client parameter, 6 
namesctl.trace_directory, client parameter, 6 — 
18 
namesctl.trace_file, client parameter, 6 ~ 18 
namesctl.trace_level, client parameter, 6 - 17 
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namesctl.trace_unique, client parameter, 6 — 18 
naming considerations, domains, 3 - 8 
naming model 
adapting to DNS, 4-3 
choosing, 4-2 
flat, 3-6 
for multiple regions, 3 - 11 
hierarchical, 3 -7 
naming standards, using existing, 4-2 
network 
changes, 3-15 
client definitions, 6-11 
communities, 3-5 
community based model, 3-4 
domain based model, 3-4 
network administration, 1 — 4 
network administrator, updating Names Serv- 
ers,3 -11 
network components, with the DDO, 5-2 to 5 
network data 
changes, 3 - 16 
changing, 3-16 
configuration, 3-17 
definition, 3-15 
definition of, 3 ~15,4-4 
maintaining, 3-15 
Names Servers in root, 3-15 
network definition, 3 — 17 
role in configuration process, 6 - 2 to 6-4 
network layout, views, 3-4 
network load balancing, for Names Servers, 5 
Network Manager installations, 3 - 8 
network object, client request, 7 — 6 
network objects, 1-5 
configuration, 3-17 
naming models, 3 - 6 
testing, 7-5 
sharing definitions, 1-4 
types, 1-5 
network protocol, 1-6 
network support considerations, Names Serv- 
er, 4-8 
NL-00462 error, 7 - 11 


NNL-00018 error, 7 — 10 
non-authoritative, in Oracle Names Server, 3 — 


non~authoritative answers, 7-9 
non-authoritative data 

in distributed installations, 7-4 

removing, 7-5 
non-authoritative response, definition, C - 12 
non—default parameters 

in SOLNET.ORA file, 5-14 

dead connection detection, 5-15 

with Dynamic Discovery, 5 - 13 to 5-15 

number of client profiles, C — 4 
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object names, using, 1-4 

operating system, executing NAMESCTL com- 
mands, A -2 

operating systems, and Oracle Names, 4-8 

operational commands, NAMESCTL, A ~2 


Oracle Names 
availability, 4-8 
client definitions, 6 - 11 
failures, 7-5 
multiple installations, 4-3 
organizational rules, 3 - 1 
supported platforms, 4-7 
user access, 4 ~6 
administration, 1-6 
benefits, 1-4 
configuration parameters, 6 — 12 
control utility reference, A -1 
CPU, memory requirements, 4 ~ 8 
description, 1-2 
key components, 2-6, 3-2 
parameters, 6 - 4 
user, 1-6 
users, 1 -6 
with the DDO, 2~2 

Oracle Names architecture 
with the Dynamic Discovery Option, 2 — 4 to 


2-6 
without the Dynamic Discovery Option, 3 - 
2to3-4 


Oracle Names control utility, parameters, 6 - 
17 
Oracle Names request, 7 - 2 
Oracle Names request form, sample, 7 -3 
Oracle Names Server 
configuration, 3 - 17 
system requirements, 1 - 6 
what is stored, 1~5 
with Dynamic Discovery Option, 1 — 6 tol 
-8 
Oracle Network Manager, 1 - 6 
administrative region, 3-2 
definition, 3-2 
one per region, 3-17 
uses, 3-17 
overriding default settings, A -3 
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parameter file, missing, 7 — 11 
parameter settings, changing, i 1 


parameters 
client, 6 - 13 
Names Server, 6 -4 
Oracle Names, 6 — 4 
Oracle Names control utility, 6 — 17 


parent region, highest level, 4 ~ 5 
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omitting, 7-8 
encryption, A -4 


NAMESCTL program, A -4 

server, 6 ~ 19 
passwords, operations requiring, A — 26 
PCs supported, Oracle Names, 4 ~ 8 
performance, C - 11 

and name sources, C - 13 
PING, time to contact server, 7-4 
PING command, 7 - 6 

using, 7~4,7-9 

NAMESCTL program, A - 13 
Planning for Oracle Names, 4-1 

choosing a naming model, 4-2 

choosing administrative regions, 4 ~4 

choosing multiple servers, 4 — 6 
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choosing nodes for Names Servers, 4-7 
platforms supported, Oracle Names, 4 -7 
policies 

distributing data changes, 3 — 16 

naming, 4-2 

recommended administrative, 4-5 
preferred Names Servers, 6 ~ 11 
privileged operations, A - 26 
program mode, NAMESCTL, A -2 
properties, changing, A - 3 
protocol, requirements, 1 — 6 
protocol requirements, 1 — 6 
protocol-based communities, 3 - 15 
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QUERY command, 7 - 6 
using, 7 -5,7-9 
using AUTHORITY, 7 -9 
using TRACE, 7 - 10 
NAMESCTL program, A - 14 
QUIT command, NAMESCTL program, A -16 
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reference, Oracle Names control utility, A — 1 
region name 
definition of, 3-10 
how to define, C - 6 
requirements, 3— 10 
region objects, 4-5 
regions 
contacting, 3 ~ 16 
entering in Network Manager, 4-5 
registration, dynamic, 1-2 
related publications, iv 
RELOAD command, NAMESCTL program, A 
-17,A-18 
reloading all Names Servers, 7-4 
reloading data, effect of, 7 - 4 
reloading Names Servers, from Network Man- 
ager, 7-4 
remote domains, definition, C -9 
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removing individual data, 7 - 6 

removing non-authoritative data, 7 - 4,7 - 5 

REPEAT command, NAMESCTL program, A — 
19 

replication, of service definitions, 1 -2,2—2,2 
-3 


request processor, activities, 2 — 7,3-3 
requests, allowing, A ~ 27 
requirements 
client configuration, 7-6 
delegated administrative regions, 3 — 16 
root administrative region, 3-15 
for Oracle Names Server, 1 — 6 
for upgrading to DDO, 5-4 
Names Server configuration, 7 -7 
region name, 3-10 
RESET_STATS command, NAMESCTL pro- 
gram, A -20 
response authority, C ~ 12 
response time 
measuring, 7 — 4 
average, A -19 
response times, displaying, A - 13 
restart, Names Server, 2 - 8 
RESTART command 
removing non-authoritative data, 7-4 
NAMESCTL program, A -21 
Roadmap for documentation, 1-7 
running without the Dynamic Discovery Op- 
tion, 1-8 
setting up a new network, 1 -7 
setting up an existing network, 1-7 
root administrative region, 3-12,3-15 
infrastructure data, 3 - 15 
requirements, 3-15 
root domain, 3 -7,3 -12 
definition of, 3-9 
root Names Servers, 3- 16 
root region, 4-5 
configuration, 3-12 
data definition requirements, 3 ~ 15 
root region’s domains, required by every re- 
gion, 3-15 


rules, for delegating administrative regions, 3 
-13 


S 


search path, determining, 7 — 10 ; 
Secure Network Services, in SQLNET.ORA 
file,5-15 
security 
database links, 7 ~ 8 
Names Server, A — 46, A — 48 
NAMESCTL program, A -4 
password, 6-19, A - 4 
service replication, 1-2 
SET DEFAULT_DOMAIN command, NA- 
MESCTL program, A ~ 22 
SET FORWARDING_AVAILABLE, NA- 
MESCTL program, A ~ 23 
SET LOG_STATS_INTERVAL command, NA- 
MESCTL program, A — 24 
SET NAMESCTL_TRACE_LEVEL command, 
NAMESCTL program, A - 25 
SET PASSWORD command, NAMESCTL pro- 
gram, A -26 
SET REQUESTS_ENABLED command, NA- 
MESCTL program, A - 27 
SET RESET_STATS_INTERVAL command, 
NAMESCTL program, A - 28 
SET SERVER command 
using, 7 ~9 
NAMESCTL program, A ~ 29 
SET TRACE_LEVEL command, NAMESCTL 
program, A -30 
set up Names Server aliases, 5-4,5~7,5-9 
setting default domains, in SQLNET.ORA file, 
5-15 


setting preferred Names Servers, in 
SQLNET.ORA file, 5-15 

setting up networks, with the DDO, 5 ~ 1 to 5 - 
17 


shared data changes, installation policies, 4-5 

sharing definitions, 1-4 

SHOW CACHE_CHECKPOINT_INTERVAL 
command, NAMESCTL program, A -31 


SHOW DEFAULT_DOMAIN command, 7-8 
NAMESCTL program, A - 33 
SHOW FORWARDING_AVAILABLE com- 
mand, NAMESCTL program, A — 32 
SHOW LOG_FILE_NAME command, NA- 
MESCTL program, A -34 
SHOW LOG_STATS_INTERVAL command, 
NAMESCTL program, A - 35 
SHOW NAMESCTL_TRACE_LEVEL com- 
mand, NAMESCTL program, A - 36 
SHOW REQUESTS_ENABLED command, 
NAMESCTL program, A — 37 
SHOW RESET_STATS_INTERVAL command, 
NAMESCTL program, A -38 
SHOW SERVER command, NAMESCTL pro- 
gram, A -39 
SHOW STATUS command, NAMESCTL pro- 
gram, A - 40 
SHOW SYSTEM_QUERIES command, NA- 
MESCTL program, A - 41 
SHOW TRACE_FILE_NAME command, NA- 
MESCTI. program, A - 42 
SHOW TRACE_LEVEL command, NA- 
MESCTL program, A - 43 
SHOW VERSION command, NAMESCTL pro- 
gram, A~44,A-56 
SHUTDOWN command 
NAMESCTL program, A ~ 45 
using, 7-2 
shutting down a Names Server, 7 ~ 2 
SMD, type, 7-5 
SNL-00821 error, 7 ~ 11 
specifying server, NAMESCTL, A -3 
SQLNET.ORA file, 7 -6,C -4 
location, 7 - 10 
editing manually, 6 — 4, 6 - 12 
NAMESCTL.PASSWORD, A -4 
security, 6-19 
START command, NAMESCTL program, A — 
46 
starting a Names Server, 5-5, 5-8, 5-11,7 -= 
2 
ca 


startup 
example, A — 46, A ~ 48 
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‘Names Server, 5-6, A- 46, A -48 
STARTUP command 
NAMESCTL program, A`- 48 
using, 5-5,5-8,5~11,7-2 
restriction, A ~4 
startup parameters, Names Server, 3 — 17 
statistics 
example, A ~ 50 
logging interval, 6-6 
interval, A -28 
Names Server, A — 50 
reset interval, 6 - 7, 
resetting, A — 20 
STATUS command 
NAMESCTL program, A -50 
using, 7-9,7 -10 
STOP command, NAMESCTL program, A -— 
52, A -53, A -55 
strategies 
for migration, B - 2 
for upgrading to DDO, 5-2 
system queries, A - 4T 
system requirements, 1 — 6 


T 


tasks, NAMESCTL program, 7-2» 

TCP/IP internet, global naming conventions, 4 
-2 

testing, server connections, 7 — 6 

testing database links, 7 - 7 

testing multiple servers, 7 — 4 

testing Names Servers, 7 -4 

testing network objects, 7-5 

time, transaction, 7-5 

time expectation, accessing a Names Server, 4 
-7 

Time To Live (TTL), C - 12 

TNS network, definition of, 3-15 

TNSNAV.ORA file, C -4 ; 

topology data, in Oracle Names Server, 3 +3 


trace file 
Names Server, 6 - 8 i 
NAMESCTL program, 6 -18 
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TRACE parameter, using with QUERY, 7 -10 
tracing, A - 30, A - 36, A- 43 
levels, A ~ 43 

analyzing failures, A - 25 

current level, A — 36 

levels, A - 25 

NAMESCTL utility, 6 — 17 

turning on, A ~3 
tracing level, 6-9 
transaction time, measuring, 7-5 
troubleshooting, Names Server failures, 7 — 8 
TTL, C-12 

effects of short value, C ~ 12 

effects on performance, C ~ 12 


pe 
database links,7-5. |; 
database service names, 7 —5 


U 

updating regions, 7-3’ 

Upgrade, gradual, 5~9.to 5-11 

Upgrade rules, for the Dynamic Discovery Op- 
tion, 5-3 to5—5 

Upgrading, from Native Naming adapters, 5 — 
13 to5-15 f 

upgrading, all existing components, 5-7 to 5 ~ 
9 


upgrading to DDO 
before you begin, 5 - 4 
requirements, 5 ~ 4 
strategies for, 5- 2 to 5-17 Ei 
user, Oracle Names, 1 - 6 
user access, database links, 7 ~8 
USING clause, in links, 6 - 20 
using NAMESCTL, 7 ~2 
using Oracle Names, with Dynamic Discovery 
Option, 1-4 to 1-6 ` 
using the default domain, 6 -12 
utility commands, NAMESCTL, A ~ 2 


Vv 


V1 connect strings, 1-5 
version compatibility, 1-4 to 1- 6 


Ww 


well-known Names Server, 1 -2,2-2 


well-known Names Servers, 2-2 


WORLD domain, 6- 11 
definition, 3 ~ 6 
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